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An experiment was conducted to study how children, 
aged 10-15 years, learn concepts relevant to computer programing and 
how they learn modern programing languages. The implicit educational 
goal was to teach thinking strategies through the medium of 
programing concepts and their applications. The computer languages 
Simper and Logo were chosen because they are computationally general, 
relatively easy to learn, interactive with powerful editing features, 
and are highly dissimilar. The experiment included significant 
tutoring, curriculum design, and various special output devices such 
as graphic displays, robots, electric trains, and sound synthesizers. 
The report is divided into six major sections: (1) introduction: 
background and motivation; (2) programing facilities; <3) student 
selection, grouping and tutoring; (4) curricula; (5) data acquisition 
and analysis; and (6) results. Among the results were suggested 
modifications to both the Simper and Logo languages and to the 
curriculum designed to teach them. (KKC) 
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2 Introduction : Background and Motivation 

In this report, we discuss in detail an experiment which took place 
at the Institute for Mathematical Studies in the Social Sciences (IMSSS) 
during the summer of 1973. A brief outline has appeared elsewhere 
(Cannara & Weyer, 1974) • We also discuss related, Informal events, 
which derived from and occurred subsequent to the experiment. 

The experiment attempted to study how children learn: (a) concepts 
relevant to computer programming, and (b) modem programming languages. 
We will discuss the languages used, why they were chosen and what the 
experiment suggested in terras of the design of the languages as well as 
programming languages in general. Because the particular concepts and 
languages were to be taught to naive programmers, tba experiment 
Included a significant tutoring and curriculum design project. This 
phase of our work Is carefully detailed. We Include discussion of 
several special output devices which the children controlled via their 
programs In order to draw lines on paper, animate pictures on graphic 
displays, move a robot, control an electric train, and synthesize sound. 
We examine these devices in terms of their motivational value to 
children, and hew and to what extent they might offer means for posing 
pedagogically useful problems to student programmers. 

The language and curriculum design aspects of this experiment were 
partly intended to lay groundwork for a subsequent, more refined study 
of children's interactions with programming. Results of that 
experiment and some further analyses of data from this experiment will 
appear in a later report (Cannara, 1975). 

1 
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It is not a new idea that children can and should learn how to 
program a computer, so that they too might access its unparalleled power 
as a tool for thinking. Various computer scientists have worked to 
cast the computer as a personal "mathematical laboratory" (Brown, Dwyer, 
Feurzeig, Kay, Papert). In 1965, Feurzeig proposed that a suitably 
programmed machine could create a constructively interactive environment 
with the potential to enhance a child *s interest and learning in 
mathematics. Since then, attempts have been made to realize such 
mathematical laboratories in contexts ranging from formal logic 
(Goldberg, 1973) and calculus (Kimball, 1973) to computer programming or 
"mathematizing" (Feurzeig, Papert, Bloom and Solomon, 1969). In such 
environments, students may enjoy broad freedom to explore, interactively 
and constructively, disciplines which are frequently deprived of 
substance by either the classroom lecture or traditional computer- 
assisted instruction (CAI). 

In any computerized implementation of a mathematical laboratory, a 
program simulates the system of interest; the student communicates 
with this simulation via a formal language. The semantics of that 
language access the constructive abilities of the laboratory, the syntax 
is Just a new set of notational conventions. Both must be considered 
carefully by the laboratory's designer and both must be mastered by the 
student. 



* The reader might examine Ellis (1974) or Oettinger and Marks (1969), 
especially Ellis' nontechnical critique of present applications of 
computers in education. 
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Of all possible mathematical laboratories, the most general are 
those which give students full computational access to a computer, by 
allowing them to write programs. The means for communicating with such 
laboratories are programming languages, which define tools available to 
anyone using the laboratories to formalize ideas. The formalization of 
ideas is a fundamental aspect of mathematics. If, by a free 
interpretation of Church s thesis , any ideas which may be formalized 
may be studied concretely via a computer program, then, by learning 
programming in full generality, students can learn how to construct 
laboratories to study any ideas they wish to think about. Furthermore, 
because programming offers a way of formalizing thoughts to produce 
concrete effects, students can learn something about thinking. For 
this reason, we and others believe that the natural place for the 
computer is in the schools, where thinking and "thinking about thinking" 
(a notion promulgated by Papert) can and should be taught. 

From an educator's viewpoint, the theory and practice of 
computation offer much: (a) the f cnnalization of ideas as sequences of 
instructions, (b) methods for modelling real-world processes, and (c) 
metaphors for describing machine and human information processing. 
These form a nucleus of thinking techniques which expose what Papert has 
termed "powerful ideas". Concepts of programming and thinking can be 
taught as natural and inseparable partners, with emphasis on improving 
students' abilities to scrutinize their own thinking about the world. 



* For discussions of this important conjecture, see Manna (1972) or 
Minsky (1967) . 



The computer's ability to simulate responds to the ingenuities of 
students (for example, see the work of Paper t, 1970 or Brown and 
Rubinstein, 1973) with the same spectacular generality it has provided 
to professional researchers (good examples are in Levison, Ward and 
Webb, 1973; in Toomre, 1973 and in Winograd, 1971). More recently, as 
computing machinery has become cheaper and more accessible, it has begun 
to pervade the high schools. It seems reasonable that this trend 
should soon extend interactive computation into the elementary schools. 

The foregoing remarks were meant to justify our desire to study 
programming as an intellectual activity for children and programming 
languages as tools for such activity • If access to interactive 
computation will soon become commonplace for vast numbers of children, 
at school or at home, then we certainly should be trying now to 
understand how to make the most fruitful use of the technology. As a 
medium for manipulating and expressing ideas, the personally accessible 
computer may stand well above everything since the printing press. It 
is important, therefore, to study the computer and children (or adults) 
as tool and users so that the tool may be honed to maximum usefulness 
(recreational, artistic or educational). 

Because it is widely believed that young children can benefit 
intellectually by learning programming, numerous research projects have 
been set up to teach particular programming languages (e.g. Feurzeig and 
Lukas 1972a; Fischer, 1973; Folk, Statz and Seidman, 1974; Milner, 

* See Kay (1972a, 1972b) or Brand (1974, pp. 64-71) for one view of the 
near future of computing. 
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1973 or Roman, 1972). However, apparently none has attempted to make 
explicit the broad range of programming concepts and their relationship 
to a student *s world of thought. In such terms, many projects have 
pursued hazy and sometimes arbitrary goals that concentrated on teaching 
an available language through ad hoc problem-solving situations* 
Little effort has been expended on generalizing those situations and the 
solution strategies used* A study by Folk, et al*, (1974) is perhaps 
the most extensive attempt to specify relationships between programming 
concepts and the development of children's thinking processes. But 
their analysis is confined to classical analysis~of -variance models and 
the concomitant testing of rather broad h3^otheses virtually ignores a 
wealth of valuable detail in student protocoxs — the type of data we 
value most. 

Teaching programming is a tutorial endeavor. A programming tutor 
must be ready to intelligently suggest, accept and comment on an 
arbitrarily wide range of student interactions and program synthesis. 
In any tutorial atmosphere, the details of errors made by a student are 
extremely useful. They do more than indicate what the student does not 
understand, they indicate how the student v^iews the problem at hand in 
terms of his or her own view of the world. Extending a suggestion of 
Papert's, if a student responds to a posed problem at all, that response 
is typically correct by the student's personal analysis. So the 
student is surprised to hear "wrong". It is the tutor's responsibility 
to try to divine the reasons for the student's error. This frequently 
means that tl.c cutor must act as does a detective attempting to elicit 
evidence from someone from a foreign land. Much of tha subsequent 



interaction must be devoted to laying a common foundation of terns — 
their definitions and relations • The tutor necessarily learns 
something about the student's world view and is better prepared to 
handle future errors and future students* 

Errors are not "bad". They provide valuable feedback to be 
exploited for a student's benefit. Because students sense this and 
respond positively, much of what is presently considered to be advanced 
research in computer-assisted instruction concentrates on establishing 
such a close relationship between tutor (albeit mechanical) and student. 

The construction of programs which can tutor humans with human 
proficiency has been the goal of many researchers. No one has been 
fully successful yet, because the fundamental activities of a good tutor 
are tied Irrevocably to humanness of language and knowledge. The 
theoretical power of a computer may be sufficient to simulate human 
intellect, but we do not understand ourselves well enough to communicate 
even a coarse description of our intellect to any recipient. Those who 
have recognized the nature of this probiam have come closest to success 
in limited contexts (e.g. Brown and Burton, 1974; Carbonell, 1970 or 
Winograd, 1971). Teaching programming is perhaps the most general 
tutorial activity one could care to mechanize, so we believe that 
detailed studies of students learning to program can help to 
characterize tutorial int ex actions in general. 

Any tutor must (a) understand ttie subject being taught and (b) 
possess a strategy for handling eriors that is adaptable to the demands 
set by individual students. Unfortunately, the bulk ot past efforts in 



CAI have bypassed (a) and have sought to discover techniques for 
manipulating student performance (most frequently measured in ways more 
convenient for the researcher than beneficial zo the student) by 
attacking (b) in narrow contexts (e.g« the reader should critically 
examine Smallwood, 1962 or the examples used by Suppes in Wittrock, 
1973). The result too often has been a simple transfer of programmed 
instruction from paper or film to computer storage, applying very 
little, from the student's vantage, of the computer's computational 
potential* Largely in conjunction with advances m artificial- 
intelligence research, (a) and (b) have been attacked together (e«g« 
Goldberg, 1973, Brown and Burton, 1974, Kimball, 1973) • 

However, any general tutorial system for teaching programming is 
destined to occasionally fail the student; because of its generality, 
it must occasionally tackle unsolvable (uncomputable) problems. In 
other words, it must pass judgment on the correctness of a student's 
programs, and we know that there exists no general procedure for 
deciding that an arbitrary program is correct or incorrect* But a 
human tutor is faced with the same situation, and the range of solvable 
problems is so broad that this hard theoretical fact has discouraged 
neither researchers nor teachers. "Proof of program correctness" and 
"automatic program synthesis" are active topics in computational 



* We agree with Dw>'er (1972) who has said that CAI fails in "reproducing 
the excitement of masterful teaching". We would add that only rarely 
have CAI workers even attempted to capture masterful teaching • 

*5^Di8cussions of the uncomputable appear in Davia (1965; and in Minsky 
(1967) • 



research which have clear bearing on future success in constructing 
competent computer-based tutorial systems. The work to be reported 
here attempts to characterize some of the situations that human and 
mechanical tutors for programming will confront and must be prepared to 
resolve. 

Our implicit educational goal is teaching thinking strategies by 
teaching programming concepts and their applications. Ideally, a 
student should look to his or her own life experience for applications 
of the tools which an understanding of the concepts supplies. This, we 
believe, is the ultimate justification for teaching programming. For 
programming to succeed (from the students' point of view) as part of any 
educational experience, we must be concerned with each student's 
individual approach to it. The power of a programming laboratory 
derives from the fact that students do more than interact with it, they 
intervene. Through its language they formulate and activate ideas and, 
in doing so, mould the laboratory to their cwn purposes. From 
primitive tools available to them at the start, they derive new ones, 
and from these, others, ad infinitum. 

That programming concepts provide an invaluable link between 
formalized thinking and perceived reality is certainly not a new axiom 
(Berry, 1964). It was assumed, perhaps tacitly, in much of the 
research quoted here. However, no study has attempted to teach a full 
range of relevant concepts from computation theory (see Table I) which 
we believe is essential to establishing that link. Another motivation 
for our work has been a desire to contrast programming languages and how 
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Table I 



Some Fundamental Programming Concepts 

1 . Machine as a tool manipulated with a command language 

2. Machine possessing an alterable memory 

3. Literal expressions 

4. Name-value associations 

5. Evaluation and symbol-substitution 

6. Execution of stored programs 

7. Programs which make decisions 

8. Procedures (algorithms) 

9. Evaluation of arguments to procedures 

10* Procedures as realizations of functions (transformations) 

11. Composition of functions 

12. Partial and total functions 

13. Computational context (local versus global environments) 

14. Evaluation In changing environments 

15. Induction (recursion and iteration) 

16. Data struct rzes as defined by functions 

17. Problem formulation (representation) 

18. Incomplete algorithms {heuristics) 
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they aid or hinder acquisition of the set of concepts we have said we 
value. Syntactic differences among languages are of but Incidental 
Interest. Most important is how the meanings (semantics) of a 
language, accessible via Its grammatical rules (syntax) and defined on 
the structure of some underlying machine, can illuminate the concepts. 
Furthermore, we feel there is a need to Investigate the educational 
value of some of the many types of devices that may be used by students 
and controlled by their programs. 

So, the problem we posed for research can be siimmarlzed in two 
questions: (a) How do the characteristics of programming languages and 
devices Influence a child's motivation and ability to learn programming 
concepts and apply them to the solution of problems? and (b) How do 
children relate programming concepts with their real-life experiences? 



2^ Programming Facilities 

Our tutorial structure attempted to impart an understanding of the 
concepts in Table I and fluency in two, very different programming 
languages. This required the development of (a) interactive 
laboratories (interpreters) for the languages and devices used, (b) 
parallel curricula for teaching the concepts, (c) means for acquiring 
data on each student's interactions, and (d) means for assessing each 
student's aptitude for programming and mastery of the concepts. 

Part of requirement (a) was easily met by using existing 
interpreters for two languages, Logo and Simper, developed specifically 
to teach children computer programming. The development of some of the 
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devices used and requirements (b), (c) and (d) defined the work to be 
done preliminary to the actual experiment. 

2,1 Languages 

The languages Simper and Logo were chosen because they are 
computationally general, they are relatively easy to learii, they are 
interactive with powerful editing features, and they are highly 
dissimilar. 

Simper was developed by Lor ton and Slimick (1969) at IMSSS as a 
simple simulation of an imaginary machine resembling an Hewlett-Packard 
model 2000* It was used to teach business applications of programming 
to students at Woodrow Wilson High School in San Francisco via remote 
lines from the IMSSS PDP-1 . Simper was implemented later on that high 
school's HP-2000F in Basic. At IMSSS, it has been expanded and 
rewritten in the Algol-60 subset of Sail (Swinehart and Sproull, 1971) 
by the authors. 

Simper, like Logo, is designed for interactive use. It is an 
assembly language interpreter for a simple decimal machine with an 
addressable program counter. Its instruction set typifies those of 
early minicomputers and is similar to, but simpler than, that of the 
language Mix (Knuch, 1970). As a programming laboratory. Simper has 
three functional components: (1) an interpreter which handles editing 
and general management of programs, (2) a real-time assembler which 
translates symbols and mnemonic instructions (listed In Table II) into 
machine language, and (3) a simulator for the underlying machine. This 
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Table II 



Simper Machine Operations 



Mnemonic Action (If not obvious) 

PUT value of address field to register 

LOAD copy value In addressed cell Into reglst'^r 

STORE Inverse of LOAD 

ADD add value In addressed cell to register 

SUBTRACT 

MULTIPLY 

DIVIDE 

LAND decimal dlglt*-wlse minimum between register and memory 

LOR decimal digit-wise maximum 

LEXOR "exclusive or": LOR except for equal digits 

JUMP transfer to address if register is non-zero 

JASK transfer to address if a key has been typed 

COMPARE three-way skip on memory cellos value greater than, 
equal to, or less than register's value 

SHIFT 
ROTATE 

EXCHANGE flip contents of two registers 

INCREMENT 

NEGATE 

ERROR overflow error code to register 

ASK decimal numeral from keyboard to register 

WRITE Inverse of ASK 

CASK ASCII character from keyboard to register 

CWRITE Inverse of CASK 

lOT input /output transfer (for graphics etc») 

RANDOM random 10-dlglc Integer to register 

TIME seconds since midnight to registe 

WAIT defer execution for milliseconds in register 

HALT stop execution 

NOP no-operation 

Typical Instructions 

ASK B Each instruction may have one, two or three parts, 

ADD B 100 (1) the operation, (2) the register and (3) the address. 

HALT 
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system allows students to generate and easily "debug" nontrivlal 
machine-language programs* 

Logo (Feurzeig, et al., 1969) is a procedural language whose basic 
data structures are strings of letters or words. In too was developed 
for children and has been used extensively in educational res^jarch. 

The Logo instruction set is easily expanded via procedure (command) 
definitions, which may be expressed recursively. Commands which a 
student defines are syntactically equivalent to Logons primitives. 
Logo contains essentials of the currently popular Basic language as a 
subset, but is superior to Basic in terms of mathematical consistency, 
and clarity of phrasing and control. In addition, Logo begins to 
address the important question of language extensibility, which we feel 
is a fundamental measure of the usefulness people can attribute to any 
language for computing or thinking. Our Logo interpreter was obtained 
from Bolt, Beranek & Newman Inc. (BBN) of Boston. It is written in 
Macro assembly language for the PDP-10. For the purposes of our 
experiment, we modified Logo to communicate with special alphanumeric 
displays, a model train, an "X-Y" plotter, graphic display terminals and 
the IMSSS digitized-audio system. During the experiment, several 
children had access to each of these devices. As a result of obvious 
student enthusiasm during the main portion of the experiment. Simper was 
later also modified to access the graphics devices. A partial list of 
IMSSS Logons primitive commands appears in Table III. 

In the body of this text, ue use paired » siiKole quotes (*) to denote 
phrases In the 10:^0 and Simper lanGua^es 
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Table III 

Some Logo Primitives (* means peculiar to IMSSS) 



Name 
TO 

RETURN* or OUTPUT 

EDIT 

MAKE 

VALUE* or THING 
it 

FRONT 

WHERE* 

PLOT 

SAY 

PRINT 

REQUEST 

SNAP* 

MOVESNAP* 

WORD 

SENTENCE 

FIRST 

RANDOM 

SAMEP or IS 

EQUALP 

IF THEN ELSE 



Action 

allows creation of a new operation (a procedure) 

allows operations to return values to the evaluator 

allows the user to change an operation's definition 

associates a name with a value 

accesses the value associated with a name 

moves the "turtle" or train forward 

returns the present location of the train 

sends turtle drawing to X-Y plotter or robot 

causes the audio system to speak a message 

causes the user's terminal to type a message 

asks the user for a message 

makes a "snapshot" of graphics picture being drawn 
moves a snapshot as part of an animated display 
combines two sets of letters or numbers Into one 
combines two words or sentences Into a sentence 
returns the first letter or wox^ In a value 
picks a digit between 0 and 9 
are two words or sentences Identical? 
are two numbers equal? 
decision making 



Typical Compound Commands 



PRINT SENTENCE "THE TRAIN IS AT:" WHERE 
FRONT RANDOM 

IF EQUALP RANDOM REQUEST THEN SAY "GOOD GUESS" ELSE SAY "OOPS" 
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The disparate natures of Logo and Simper are demonstrated by two 
sample dialogues (Figure 1) which produce alternative programs for the 
repeated printing of a keyboard character supplied by the typist. In 
the figure, prompts from Simper are the current memory address (a 
decimal numeral) and a or an depending on whether the addressed 

location Is empty or used. Logo prompts at the outer level and 
at the editing level c A "fG" indicates a control character typed by 
the user to stop a potentially endless execution sequence. 

Many readers may not be familiar with Logo and most will not be 
familiar with Simper. The next two sections are Intended to fill such 
gaps. An appreciation of both languages should naturally grow as we 
discuss the curricula, student data and results later on. The 
Importance of powerful editing and debugging features in Logo and Simper 
should become especially apparent. As part of the analysis of student 
interactions, we will discuss changes we have made, or would like to 
make, to Logo and Simper. A few changes are evident in Tables II and 
III, which show the states of Simper and Logo after the experiment 
(e.g. after che addition of graphics capability to Simper via the 'lOT' 
operation, and new, or alternace command names, such as 'RETURN', in 
Logo) . 

2. 1 > 1 Command Parsing and Execution 

As outlined above, the Simper interpreter allows its user three 
basic abilities: (1) entry of machine-language instructions, (2) entry 
of assembly-language mnemonics and symbols, and (3) various editing and 
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SIMPER 



LOGO 



001 :PUT A 43 

002 :NAME REPEAT 

002 ICWRITE A 

003 :PUT P REPEAT 

004 :RUN 

EXECUTING 1 TO 500 

I I 1 1 1 1 1 1 1 1 I tG 

...23 INSTRS IN .043 SEC. 



_T0 REPEAT :LETTER: 
@10 TYPE tLETTER: 
920 REPEAT :LETTER: 

qend 

repeat defined 



_REPEAT "+" 
I I 1 1 I I I I I I ItG 
I WAS AT LINE 



10 IN REPEAT 



004 :EDIT 1 

001 'CASK A 
004 : SLIDE 2:7 

002 :ASK B 

003 : NEGATE B 

004 :JUMP B .+2 

005 :HALT 

006 INCREMENT B 

007 INAME 4 REPEAT 
SWITCHING REPEAr'S REFERENCES 
007 !RUN 

EXECUTING 1 TO 500 
+10 

! i ! I ! I I ! i j 

HALT... 45 INSTRS IN .117 SEC. 
007 !LIST 
YOUR PROGRAM: 



_EDIT REPEAT 
@EDIT TITLE 

@TITLE TO REPEAT : LETTER: : TIMES: 
@5 TEST LESSP :TIMES: 1 
@7 IFTRUE DONE 
@EDIT LINE 20 

20 REPEAT :LETTER: DIFFERENCE :TIMES: 1 
(SEND 

REPEAT DEFINED 

JREPEAT "+" 10 
I I I 1 1 I 1 1 I l _ EDIT REPEAT 
(§6 IFTRUE SKIP 
(iEND 

REPEAT DEFINED 

_REP'£AT "+" 10 
j i I j j i i i i ! 

_LIST REPEAT 

TO REPEAT : LETTER: : TIMES: 



001 ! 


CAS A 




5 TEST LESSP : TIMES: 1 


002 ! 


ASK B 




6 IFTRUE SKIP 


003 ! 


NEG B 




7 IFTRUE DONE 


004 


lJUM B 


.+2 (REPEAT) 


10 TYPE : LETTER: 


005 


:HAL 




20 REPEAT : LETTER: DIFFERENCE 


006 


!INC B 






007 


ICWR A 






008 


[PUT P 


REPEAT 





Fig. 1. Simper and Logo Sample Dialogues. 
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other commands for program managements For category (3), only the 
syntax of commands will be discussed here; details appear in the next 
section. One can imagine that, when the Simper interpreter is not 
running a user's program, it is simply waiting for a message from the 
user which either falls into one of the three categories above or is 
unintelligible • 

The underlying machine simulated within the Simper interpreter 
operates on decimal numerals (words), some of which it "understands" as 
legal instructions. The size and number of memory and register words 
is adjustable whenever the interpreter is compiled* The machine's 
organization was as shown in Figure 2. Each of the 250 memory cells 



Registers 
(10 max.) B: . c • , ^ . . -> * 

(program counter) P: 



Memory Cells 
00 Is CO 
00 2* 



250: . e , (511 max. ) 



Instruction Foinnac 
seven digits: 

0 r a 
p e d 
e g d --(indire::t flag & address) 
r i r 
a s e 
t t s 
i e s 
0 r 
n 



Fig* 2 Structure of Simper's Simulated Machine 
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and each register could contain a ten-digit decimal numeral. The 
program counter is simply the "P" register, whose content Is usually the 
memory address of the next instruction to be obeyed. That content can 
be changed by any instruction which chooses to write into P. 
Instructions are seven-digits in length and are partitioned (see Figure 
2) into three fields: operation, register, and indirect address flag 
and address. 

Each operation mnemonic in Table II has a corresponding two-digit 
code, each register has a one-digit code. The four-digit field used 
for addressing may be filled in various legal ways, depending upon the 
operation to be obeyed. For some operations, the register and/or 
addresp fields are not used and can be filled out with zeros. A user 
may type any legal, seven-digit instruction numeral to the interpreter 
and it will be stored in the memory location whose address appeared in 
the interpreter's prompt (e.g. to the left of the in Figure 1)* In 
fact, any numeral, up to ten-digits in length, can be entered into 
memory this way. Whenever such a message is stored, the next prompt 
given the user will refer to the next available memory cell. 

Assembly language instructions are translated (by a "real-time" 
assembler) into machine language numerals which are, in turn, stored in 
the prompted memory cell. The three fields of the target numeral are 
synthesized from three spaced fields of mnemonics or numerals typed by 
the user. In this way, machine and assembly language may be mixed 
within one typed instruction. Translation of instructions which 
contain no symbols (no names such as 'REPEAT' in Figure 1) is direct. 
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Sjnnbolic addresses are looked up in a symbol table which is up-dated 
each time the 'NAME* command is used* Because real-time assembly must 
account for possible editing changes, a symbol may be used in an address 
field before 'NAME' has identified it with a cell. In such a case« the 
address field of the machine instruction is zero and another table, with 
an entry for each memory cell, is marked to show that the instruction 
must have its address field "fixed up" if the sjnnbol ever becomes 
attached to some cell* This additional table, parallel to memory, is 
also used to hold Intormation on relative addresses, comments entered 
with instructions, and which cells are named. The need for such extra 
storage, invisible to the user, will become clearer when Sipoer's 
editing features are discussed in the next section. 

Program management is handled by a set .of Immediately executable 
commands (Table IV). These cannot be executed from within a user's 
program, and so may be considered a separate language. Syntactically, 
however, they are similar to assembler instructions. They may have one 
to three fields (e.g. 'LIST', 'DUMP 4:00+1', and 'NAME 4 REPEAT'), the 
latter two of which are subject to assembler addressing syntax (plus the 
range operator read as "to"). 

Execution of Simper programs is initiated with the 'RUN' command or 
continued with 'GO'. The value in register P is always used as the 
address from which to fetch the next instruction, and it is incremented 
by one just before that instruction is executed. Errors detected at 
this time are: (1) an illegal program-counter value, (2) an attempt to 
execute a noninst ruction, or (3) a zero address resulting from failure 
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Table IV 
Simper Interpreter Commands 



Name Action 

DUMP display decimal content of memory and registers 

(symbols too) 

LIST or DEBUG display memory content In assembly language 

(and machine language, DEBUG shows ''secret" tables) 

RUN execute part or all of a program (and display registers) 

GO continue execution (and display registers) 

EDIT or FIX change the content of one or more memory cells 
(and show prior content) 

SLIDE relocate part or all of a progr&Ti In memor^ 

SCRATCH erase part or all of a program 

NAi«IE attach a symbol to a memory cell 

(and say how much room remains for symbols) 

FORGET erase a symbol 

NAMES list all symbols and their associations 

(and their values) 

SAVE write memory onto long-term storage 

GET inverse of SAVE 

FIELDS allow abbreviated instructions 

NEWS obtain the latest system news 

HELP obtain general information about Simper 

GOODBYE log out 

control-G stop any activity 



Parenthesized phrases describe options explained in the text* 
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to use 'NAME' to bind a symbol to a cell. If an error message is 
generated, execution is stopped. During execution, other kinds of 
errors, such as overflow, may occur which may or may not cause a halt. 
If there is an error halt or a user interruption, P's value is saved. 
The user can edit the program and then type 'GO' to continue execution. 

The effect of executing an individual instruction may be a change 
in the values in registers or in memory cells, but not in both types of 
storage. 'STORE' and 'LOAD' copy values nondestructively in opposite 
directions between registers and memory cells; 'EXCHANGE' flips the 
values in two registers; 'lOT' may copy or change more than one memory 
cell; and 'NOP' does nothing. For arithmetic and logical operations 
('ADD' through 'LEXOR' in Table II), results of a computation are always 
left in the register mentioned in the Instruction's register field. 
'DIVIDE' is a special case because iu computes both a quotient and a 
remainder, leaving them respectively in the mentioned register and the 
one adjacent to it. 

Logo's interactive structure is more nearly unitary. Its basic 
piece of executable code is a line composed of one or more commands, and 
its basic piece of program or procedure (operation definition), is a 
series of lines ^ The Logo interpreter is always executing (or capable 
of executing) a user's commands, which may call upon Logo primitives or 
the user's own procedures. Control returas to the user only when his 
or her last command and any commands it might have called have 
terminated naturally or been aborted. A few of Logo's primitives may 
not be executed directly by a user's procedure, but there is not a 




strict distinction between two sets of commands as exists In Simper. 
However, a qultk In Logo's evsluaticn scheme Imposes a different syntax 
on editing ana management ::jmmando versus c*-her primitives and user 
procedures. We will discuss this later when we take up questions of 
language design 9 

A command to the Logo Interpreter consists of two parts: (1) the 
command name (operation) and (2) an argument list, (e.g. 'PRINT 
"HELLO"*). The appropriate number of arguments must appear after each 
primitive operation or user-procedure name in any syntactically legal 
command. Thus, Logo is inherently a prefix language. Evaluation of 
non-editing commands is fully general: arguments may be supplied by 
constants, vaciaolas or executable commands (see the bottom of Table III 
for some ex^amples) . 

The basic data structure in Log-^ is the character string. This is 
broken into two subclasses: words and sentences. A Logo sentence is 
any string containing woi'ds separated by spaces, A Logo word is any 
string of le-ters, digits and punctuation. Numerals are simply a 
subclass of words > Alth.^^gh Logo's arithmetic operations are 
restrlc^-ed Co integers, arguments may be ox arbitrary length (i.e* 
unlimited magnitude) « 

There are three ways to access data in Logo: (1) as constants, (2) 
as value© recumad by executed c commands, and (3) as values associated 



* The version of Logo used in this experiment also allows infix notation 
for arithmetic opa-^anions like: '3+4', but wa felt this to be an 
Inconsistent feature and disabled li, e.g^ to allow only: 'SUM 3 4'. 
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with names. Constants (literals) are either quoted strings or signed 
numerals* A quoted string may be a word or a sentence • Quoted 
numerals are treated as if they were unquoted^ Any value that may be 
expressed as some combination of constants, named values, or values 
returned by commands may itself be returned by a command, or be 
associated v/ith some name (see Table . Ill and Figure 1 for some 
examples). A value is associated with a name by instantiation of a 
procedure's argument, or by the 'MAKE' operation (e.g. 'MAKE "CAT" 
"MEOW"'). It is referenced by the 'THING' or 'VALUE' operation or by 
surrounding the name with colons (e.g. the two commands: 'PRINT VALUE 
"CAT"' and 'PRINT :CAT: ' would each produce "MEOW"). Values may also 
be used as names, allowing any depth of indirect addressing (e.g. 
executing 'MAKE :CAT: "NOISE"' would allow 'PRINT :MEOW: ' to produce 
"NOISE") . 

Logo stores procedure (operation) names and names of values 
distinctly. This allows construccions like: 'PRINT :VALUE:', which 
does not execute the 'VALUE' operation. Procedure text is only 
accessible via certain operations, but, with these, programs can modify 
themselves. A schematic of Logo's memory space appears in Figure 3. 

A procedure is defined by the user with the 'TO' operation, which 
expands Logo's internal dictionary of the operations it can obey. A 
procedure definition takes the form of a title and a body. The title 
states the name of the new operation and the names to associate with any 
values it should expect as arguments. The body consists of a sequence 
of numbered lines. Each line ±s itself a Logo command; line numbers 
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serve as editing handles and define the sequence in which the lines will 
be executed* 

Evaluation of a Logo command implies execution of at least the 
operation (s) named and perhaps other commands, as arguments or possible 
side effects. Because of the prefix nature of Logo's syntax, Logo 
processes a coimmind in two steps, first parsing left to right until a 
subcommand is found which has sufficient input arguments for execution, 
and then returning values from right to left as it executes any 
subcommands suspended for want of computed arguments. Often these two 
steps will alternate as a command is obeyed. Implicit in this 
processing scheme is a mixture of evaluation and execution mediated by 
an ability to preserve, and later restore, the information associated 
with any subcommand (s) /nose execu::ijn must be suspended when other 
execution is called fcr. This processing naturally extends to user 
procedures which Jtall other procedures, use primitives, or call 
themselves. ti :larifying example fellows- 

The unde "lying structure which allows Logo's form of processing is 
the "execution scack" in Figure 3 — • a standard "last-in-first-out" data 
struccuze fe^g Evey^ 1963)., Infcnna*.ion enters and leaves the stack 
only via its "topmost" cell. As Logc pie3eT:*ves information pertaining 
CO commands wh^se exe*ucicn has been suspended, the a tack acquires the 
execution history of a picgram as a list of things left undone — most 
recent history on top. Normally, information added to the stack is 
later removed, bacause susparidad commands dXQ eventually obeyed. The 
stack Is uc^ually empty boch before and alter a user*s command to Logo 
has been cbcyed« 
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user procedure 
definitions 
(editable) 
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user abbreviations 
(modifiable) 
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user names 
(modifiable) 



Legend 

LLL denotes a link that L^go can exploit 

UUU denotes a link rhat the user can exploit 

uuu denotes a link to which the user has partial access 



Fig^ 3. Schematic of Logo's Memory Space. 
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Readers unfamiliar with this evaluation method are urged to use 
Figure 4 to follow the effect of the command: 'PLAY*, assuming the two 
procedure definitions: 

TO PLAY 

10 TYPE "WHAT NUMBER AM I THINKING OF?" 

20 PRINT GUESS RANDOM REQUEST 

END 

TO GUESS :IT: :THAT: 

10 IF EQUALP :THAT: :IT: THEN RETURN "WOW" ELSE PRINT "TRY AGAIN" 

20 RETURN GUESS :IT: REQUEST 

END 

They are printed here exactly as a user would have typed them to Logo* 
As part of our results, we will consider student errors related to 
Logo's command-evaluation method. 

Whenever 'GUESS* is executed, it expects to receive two input 
values (via the stack) which it will associate with (bind to) the names 
'IT* and "THAT*. Whenever 'IT' or 'THAT' is evaluated (e.g. line 10), 

if 

Logo searches the stack for the first (latest) such binding. The 'IF 
... THEN ... ELSE structure is an execution selector — 'IF' 

receives either "TRUE" or "FALSE" from 'EQUALP', causing Logo to execute 
either the command marked by 'THEN' or that marked by 'ELSE'. Here 
'GUESS' either may return a value ("WOW") by replacing its own name in 
the stack, or it may defer returning a message and call on itself (line 
20) recursively. This creates a new copy of 'GUESS' on the stack 
without destroying the old copy. I^hen 'RETURN "WOW"' is executed by 

* Logo is derived from Lisp, so inputs are not "local variables" in the 
Algol sense, although locals may be defined in Logo. 
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(a) Logo about to execute line 10 in PLAY (b) line executed 

-JL'^WHAT NUMBER AM I THINKING OF?" I PLAY (resuming) 

I TYPE (awaiting 1 input) ^ 
J^PLAY (resume after line 10) 



(c) starting RANDOM 
J_RANDOM 

I GUESS (awaiting 2 inputs) 
IMPRINT (awaiting 1 input) 
l^PLAY (resume after line 20) 



(d) starting GUESS 

L.2 (returned by REQUEST) 
I_3 (returned by RAi\IXJiH) 
l^GUESS 

IMPRINT (waiting) 
JLPLAY (to resume) 



If" on stack) 
"thai") 



(e) starting EQUALP 

^3 (latest value for 
^2 (latest value for 
^EQUALP 

.IF (awaiting 1 input) 
^tTHATi m 2 (GUESS* 2nd input binding) 
jmt m 3 (GUESS' I8t input binding) 
^GUESS (resane after line 10) 
.PRINT (waiting) 
.PLAY (to resume) 



(f) starting IP 
._"false" 

1_:THAT: m 2 
l.:lTi M 3 
i^GUESS (to resume) 
i^PRXNT (waiting) 
1.PLAY (to resume) 



(g) starting the "eLSe" part 

JL**TRY again" 
rPRINT 
.^tTHATt « 2 
._jITt a 3 
.^GUESS (to resume) 
.^PRINT (waiting) 
CpLAY (to resume) 



(h) GUESS calling GUESS 

1^3 (returned by REQUEST) 
._3 (latest binding of IT") 
.^GUBSS (new copy) 
HkETUKN (awaiting 1 input) 
I tTHAT: « 2 
,_tlTt m 3 
.^GUESS (to reeume) 
CprINT (waiting) 
l^PLAY (to resume) 



(i) copy returning "wow" 

LRETURN 
.^tTHATj m 3 
ZtlTt m Z 

1 GUESS (resume after line 10) 
I.RETURN (waiting) 
rtTHATt « 2 
,_tIXt « 3 
^^GUESS (to resume) 
X.PRINT (waiting) 
J^PLAY (to resume) 



(J) GUESS returning "wow"* 

t-wow- 
RETURN 

ttTHATt » 2 
tITt « 3 
J^GUESS (to resume) 

t PRINT (waiting) 
PLAY (to resume) 

(k) about to complete PLAY 
PRINf 

PLAY (to resume) 
Pig. 4. An Example of Logons use of Its Execution Stack. 
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some copy of 'GUESS', a virtual bucket-brigade sends ''WOW" back to 
'PRINT' (in 'PLAY') by removing information from the stack as each 
suspended 'GUESS' returns (line 20). A procedure may also simply 
execute without returning a value. 'PLAY' does this by default (by 
running out cf lines); equivalently, it could have contained a line 30 
which just said: 'DONE'. Alternatively line 30 could say: 'PLAY'. 
The reader should pursue the effect of that change. 

2.1.2 Editing and Debugging Facilities 

In both Simper and Logo, editing may be categorized as either: (1) 
line editing, or (2) program editing. Most of the basic line-editing 
abilities in either language arise from a machine instruction peculiar 
to the IMSSS time-sharing system. 

A "line" is any string of keyboard characters terminated by any of 
a small set of keys (e.g. carriage return). As Table V suggests, a 
line may be edited or extended before such termination by any of several 
"control-characters". As the Table indicates, some commands were 
implemented only in Logo. Commands like "control-N" mesh well with 
Logo's sentences, but were not needed in Simper because of the short, 
simple nature of Simper's instructions. 

Program editing in Simper is mediated by: (1) program-displaying, 
and (2) program-altering commands (again see Table IV). 'DUMP', 'LIST' 
and 'NAMES' fall into category (1). Since a program is stored as 
numerals in memory (viewable with 'DUMP'), 'LIST' must translate 
numerals back into assembly language whenever they appear to be legal 
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Table V 

Simper/Logo Line-editing Commands (* means Logo only) 



Name 

control-A or 
rubout 

control-W 

control-X 

control-R 

linefeed 

return or 
altmode 

control-N 

control-S 
control-E 



Action 

erases the previous character typed 

erases the previous word cyped 

erases the whole line (also control-U in Simper) 

retypes the present line minus deletions 

continues a line beyond 72 characters 

terminates a line (altmode is also known as ^'escape" or 
"enter'') 

Insert (into the present line) the next word from the 
previous (or edited) line 

skip the next word from the previous (or edited) line 

insert everything remaining in the previous (or edited) 
line into the present line 



instructions. This is true even for instructions which can be 
generated ambiguously. For example: 'ADD A 100', 'ADD A IT+2' (where 
098 is named "IT") and "lOl :ADD A all translate into: *2110100'. 

How then to translate '2110100' back into the form that the user 
obviously preferred? That is facilitated by a table, parallel to 
memory. Among other things, each cell in this table holds information 
about the nature of the address referenced by the instruction in its 
companion memory cell (see Figure 5) . If the user tjrpes an assembly 
language instruction containing a relative and/or symbolic address, the 
appropriate entries are made in the table as the instruction is 
assembled into memory. Note from Figure 5 that if an address field 
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Symbol Table Auxiliary Table Memory 




cell 


which 


which 


sign 


relative 


symbol 


names a 


named? 


name? 


remark? 




offset 


addressed 


cell? 



Fig. 5, Supporting Structure for the Simper Assembler ♦ 

contains a symbol, a pointer Into the sjnnbol table Is stored; If It 
contains a relative offset, the amount and sign are stored ♦ 
Furthermore, If a cell has a name or a remark (comment) associated with 
It, that Information Is stored as well» Although the auxiliary table 
Is Inaccessible to the user (normally Ignorant of ^DEBUG^, It provides 
a valuable service to *LIST* for Its task of reconstructing assembly 
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listings. It also facilitates other editing services, as we will 
mention. The symbol table may be Inspected by the user with the 
^NAMES* command — the addresses and contents bound to all sjrmbols are 
displayable. 

A program may be altered by any of: ^EDIT^ 'SLIDE', 'SCRATCH', 
'NAME' and 'FORGET'. 'EDIT' effectively places the user anywhere in 
Simper's memory so that any nximber of contiguous locations can be given 
new contents. When all the requested locations have been visited, 
'EDIT' returns the user to the address from which the original command 
was given. For example: "003 :EDIT 5:7*' would prompt "005 through 
"007 :'* and then return to "003 One may see the present content of 

a location to be edited by terminating an 'EDIT' command with the 
"altmode" key rather than the "carriage return". The standing rule in 
Simper is that terminating a command with "altmode" is equivalent to 
requesting whatever extra information that command can supply. The 
extras are parenthesized in Table IV 

'SLIDE' is the most powerful editing command available in Simper. 
It allows one tc relo^^ate a block of code in memory without having to do 
additional editing to tix up addresses which point into or out of that 
blocks A program is essentially executable after any 'SLIDE'. 
Examples appear In Figure 6. The command can move a block (a 
contiguous group of non-zero memory values) either forward (to higher 
addresses) or backward (to lower addresses) in memory. A move forward 
allows the user to create an empty region for insertion of new code, A 
move backward destroys any old code in the region covered by the new 
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(a) Opening up space fcr new instructions: 



before the command: * SLIDE 3:5*, and after 



001 :ASK A 


UU 1 • 


AO IS. 




002 :MIIL A 10 


002 : 


MUL 


A 10 


003 :ADD A 6 


003 : 






004 :WRI A 


004 : 






U05 :PUT P 1 


005 : 


ADD 


A 8 


006 :9 


006 : 


WRI 


A 


007 : 




007 : 


PUT 


P 1 


008 : 




008 : 


9 




009 : 




009 ! 






010 :2 


010 ! 


2 




(b) Replacing an undeslred 


sequence of code: 




before the command: 'SLIDE 


5:3', and after 




001 ! 


ASK A 


001 


lASK 


A 


002 ! 


MUL A 10 


002 


IMUL 


A 10 


003 ! 


JUM A .+1 


003 


lADD 


A 6 


004 


PUT A 1 


004 


IWRI 


A 


005 


ADD A 8 


005 


:PUT 


P 1 


006 


iWRI A 


006 


!9 




007 


PUT P 1 


007 






008 


!9 


008 






009 




009 






010 


!2 


010 


:2 





Fig. 6. Two Uses of Simper *s * SLIDE* Command. 



position of the relocated block. If one wishes to erase but not move a 
certain region In memory, then * SCRATCH* Is useful. Both * SLIDE* and 
*SCRATCH* appropriately revise the supporting tables (In Figure 5). 

Symbols are created with *NAME* and destroyed with *FORGET*. Any 
memory cells may be named. *NAME* writes the symbolic name and lt*s 
associated cell*s address Into the symbol table. A symbol also may 
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spring into existence if it is used in the address field of an 
in8truc::ion«. In such a case, the name is entered into (or matched in) 
the symbol table and a pointer to it is installed in the proper cell 
(Figure 5, subcell: "symbol addressed") of the auxiliary table. If 
'NAME' has not yet been used to tie that symbol to some memory cell, 
then both the address field of the assembled instruction and the 
"address" subcell of the S3nnbol table entry must remain blank. This 
condition is indicated by setting the "names a cell?" subcell to "no". 
Should the symbol ever be tied to a cell, the assembler searches memory 
and "fixes up" the address fields of instructions so marked. The 
association of a symbol may be moved from one memory cell to another 
with 'NAME'. This may also result in reassembly of the address fields 
of some instructions. 

'FORGET' cannot erase a name from the symbol table as long as that 
name is referenced in any address fields This is designed to protect 
the user, lest he or she suddenly be confronted with many instructions, 
in a complicated program, whose address fields wee redundant and/or 
meaningless. 

Some miscellaneous commands are available to the Simper programmer. 
A program may be saved on and later retrieved from the operating 
system's long-term storage by using *3AVE' and 'GET' respectively. 
This entails saving only the essentials needed tc reconstruct the tables 
depicted in Figure S. Another command: 'FIELDS' can be used to reduce 
the typing needed for instructions which use the A register. This 
command is a toggle which, when turned on, tells the assembler: "l want 
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in the register field unless I say otherwise." For example, with 
the toggle on, the first program in Figure 6 could have been typed: 

ASK 
MUL 10 
ADD 6 
WRI 

PUT P 1 

and it would have been so listed (by 'LIST') as long as 'FIELDS' was not 
used to reset the toggle. This feature provides a convenient 
simulation of a single-register machine. Finally, one of the most 
important commands available to the user is "control-G", which aborts or 
nullifies the effect of any other command and returns the user to the 
outer level of the Simper interpreter. 

Since the basic piece of any Logo program is the procedure, program 
editing in Logo amounts to procedure creation, deletion and 
modification. 'TO' and 'ERASE' handle the first two activities, while 
'EDIT' and several contingent operations (Table VI) handle the latter. 
The interpreter enters editing mode (signified by the prompt: see 
Figure 1) whenever a 'TO' or an 'EDIT' command is given. During 
editing, any other executable Logo command may be given. In fact, some 
operations (indented in Table VI) only have meaning in this context, and 
several expect input messages that define their scope (Figure 1 should 
be examined together with Table VI). However, the syntax of these 
commands does not match that outlined in the previous section. In the 
available version of Logo, inputs to operations like 'TO' or 'EDIT' are 
not subject to normal evaluation rules; rather, they are quoted by 
default. For instance, it is not possible to directly pass the name of 
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Table VI 

Logo's Procedure Editing and Debugging Cotmaands 



Name 

10 

EDIT 
TITLE 
EDIT TITLE 
LIST TITLE 
EDIT LINE 
ERASE LINE 
LIST LINE 

END 

LIST 

ERASE 

ERASE ALL 
PROCEDURES 

LIS I ALL 
PROCEDURES 



Action 

begin defining a new procedure 

begin modifying an existing procedure 

redefine the name of the procedure and Its Inputs 

change part of the title 

display the title 

change part of any line In the procedure 
delete any line 
display any line 

stop editing the procedure's definition 
display any procedure's definition 
delete any procedure's definition or trace 
delete all definitions 

display ail definitions 



LIST CONTENTS display the titles of all defined procedures 

dlapliy the user's abbreviations for all operations 



LIST ALL 
ABBREVIATIONS 

TRACE 



BREAK 

EXIT 

GO 



display a procedure's arguments 're turned value whenever 
ic is executed 

halt execution (same as control-G) 
halt and print a message 
continue execution 



Indented command? may only be given after editing has bean begun with 
To' cr 'EDIT'. 
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a procedure to be edited (e.g. *Y*) via a value bound to some variable 
(e.g. 'EDIT :X:' isn't legal, 'EDIT Y' or 'DO SENTENCE "EDIT" :X:' are). 

Logo saves the full text (expanding abbreviations) of lines and 
titles of procedures as the user defines them. The interpreter does 
not regenerate listings from some internal code as Simper necessarily 
must* This conveys two benefits: (1) the user may write procedures 
which in turn copy, edit or write new procedures, and (2) the Logo 
interpreter readily brings forth any parts of lines to he edited. (1) 
derives from normal Logo primitives, while (2) derives from the 
implementation of "control-N", "control-S" and "control -E" (Table V). 
These three commands can access a stored line and control its injection 
into the user's typing. Since procedure lines and titles are stored, 
old lines can be used to construct new ones. Suppose for example, that 
one wishes to edit the one line in the existing procedure listed below 
and add a new, similar line. 

TO WELCOME 

10 SAY "HELLO THERE" 

The command: 'EDIT LINE 10' causes the line number "10" to be printed 
and inserted into Logo's Input buffer just as if the user had typed it. 
Thus the line number may be erased or changed. At this time, Logo has 
grabbed the existing text of line 10 and knows 'SAY' to be its first 
word. Here is the editing sequence which produces line 20 by using 
line 10 ("t" means "control-", Logo's typing is in lower case, deleted 
characters are in brackets) : 

10 [ 01]20 tNsay "tStNthere" [ "] GOES A WELCOME" 
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Normally, the control characters are not printed on the user's terminal 
and, on graphics displays, delated characters simply disappear. The 
pirocedure would now have the lines: 

TO WELCOME 

10 SAY "HELLO THERE" 

20 SAY "THERE GOES A WELCOME" 

If the user were now to type "control-E", the entire text of line 20 
would be made available again for editing. This Is because Logo always 
sequesters a copy of the last line terminated by the user. Its text Is 
available at any time until another line terminator Is typed. Because 
all llne-edltlng commands operate Independently of procedure-editing 
commands, one can, for Instance, type; 

SAY "GOODBYE" 

30 tEsay "goodbye" 

to test a command before storing It as a line In the procedure being 
edited. Such access to previously tjrped lines can save the user much 
typing and reduce typing errors. 

Logo also has provision for saving programs on and restoring them 
from the operating system's file storage (see Table VII . The 
structure is more complex than Simper's, allowing all of Logo's memory 
(all procedures, bindings and abbreviations) to be saved as an "entry" 
on a file. Each file may have many entries and more than one entry may 
be read into memory at once, thus allowing programs to be combined ♦ 
Files may be examined and entries may be erased without being read Into 
active memory. The syntax of these commands is like that of the 
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Table Vll 
Logons Flle-manlpulatlon Commands 



Name 
SAVE 

GET 

LIST FILE 
LIST ENTRY 
LIST PROCEDURES 
LIST CONTENTS 
LIST ABBREVIATIONS 
ERASE ENTRY 
COPY 



Action 

replace an entry on a file with the current 
contents of memory 

append the content of an entry to memory 

display the entry names in a file 

display everything in an entry 

display only the procedures in an entry 

display the titles of an entry *s procedures 

display the abbreviations in an entry 

delete an entry from a file 

copy a text file to or from a file entry 



editing commands discussed above. Later, wb will discuss the effect on 
students of that and of the relative complexit/ of Logons filing system. 

The user can supply new abbreviations, or use those which Logo has 
built in, for relatively wordy Logo operations such as those listed in 
Tables III, VI and VII. 

Debugging . Program debugging in Simper is facilitated primarily 
by using the register displaying option of the 'RUN* command (Table IV), 
which is activated by terminating the command with the "altmode" key. 
Also, the user may stop a program at any point with "control~G", examine 
memory and register values v;ith *DUMP\ *LIST* or *NAMES\ perhaps do 
some editing and then continue the execution with *G0\ Stopping a 
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program in this way does no violence to the state of the machine; the 
program counter (P) is always saved to anticipate the use of 'GO'. The 
user may continue execution for a specific number of instruction cycles 
(e.g» 'GO 5') «iid/or alternate execution periods with the register 
display on and off. He or she also may run selected portions of a 
program (e.g. 'RUN 4:12') to check their operation. In Figure 7, we 
show a typical display for a run of the first program in Figure 6. 



007 :RIJN$ denotes altmode) 

13:04:12 (the time) 
mCUTING 1 TO 500 



P: 


A! 


B: 


INSTR: 




1 


0 


0 


ASK A 


INPUT NUMBER: 4 ("4" typed by user) 


2 


4 


0 


MUL A 10 




3 


8 


0 


ADD A 6 




4 


17 


0 


WRI A 


NUMBER=17 


5 


17 


0 


PUT P 1 




1 


17 


0 


ASK A 


INPUT NUMBER :0 


2 


0 


0 


MUL A 10 




3 


0 


0 


ADD A 6 




4 


9 


0 


WRI A 


NUMBER=9 


5 


9 


0 


pur P 1 




1 


9 


0 


ASK A 


INPUT NUMBER: -4 


2 


-4 


0 


MUL A 10 




3 


-8 


0 


ADD A 6 




4 


1 


0 


WRI A 


NUMBER=1 


5 


1 


0 


PUT P 1 




1 


1 


0 


ASK A 


INPUT NW'ffiER: tG (user aborts) 


..15 


INSTRS 


IN 


1.100 SEC 





007 :G0 4 (continue a bit with no display) 
2 

13 



...4 INSTRS IN .042 SEC 



Fig» 7. Displaying a Simper Program's Activity. 
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Without this display, the user's program has full control over the 
formatting of its output. 

Program debugging in Logo centers on the use of the commands 
'TRACE' through 'GO' of Table VI* "Control-G" and 'GO' have the same 
functions in Logo as in Simper, although 'GO' did not always work 
successfully in our version of Logo. 'EXIT' and 'BREAK' are simply 
ways of returning control to the user when some condition defined by the 
user occurs. 'TRACE' is the most important debugging command in Logo. 
It allows the user to follow a particular procedure's (but not a Logo 
primitive's) execution history, observing its arguments when it is 
called and the value it returns when it is done. For recursive 
procedures, each copy is so observable. Figure 8 shows an example 
generated by the commands: 'TRACE ACKERMAN' and 'PRINT ACKERMAN "XX" 
"Y"', that executed the procedure: 

TO ACKERMAN :X: :Y: 

10 IF EMPTYP :X: THEN RETURN WORD :X: "Y" 

20 IF EMPTYP :Y: THEN RETURN ACKERMAN BUTFIRST :X: "Y" 

30 RETURN ACKERl'lAN BUTFIRST :X: ACKERMAN :X: BUTFIRST :Y: 

realizing a string example cf Ackerman's function. In the figure, 
inferior context (a copy) is indicated by indentatioi':. The reader 
should try to justify the traced execution sequence with the procedure's 
definition and its first call. Notice that 'ACKERMAN "XX" "Y"' first 
causes the execution of 'ACKERMAN :X: BUTFIRST :Y:', at the end of line 
30; that call is the next indented line in the trace. 
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JTRACE ACKERMAN 
_PRINT ACKERMAN "XX" "Y" 
ACKERMAN OF "XX" AND "Y" 
ACKERMAN OF "XX" AND "" 
ACKERMAN OF "X" AND "Y" 
ACKERMAN OF "X'.' AND "" 
ACKERMAN OF "" AND "Y" 
ACKERMAN RETURNS "YY" 
ACKERMAN RETURNS "YY" 
ACKERMAN OF "" AND "YY" 
ACKERMAN RETURNS "YYY" 
ACKER^IAN RETURNS ."YYY" 
ACKERMAN RETURNS "YYY" 
ACKERMAN OF "X" AND "YYY" 
ACKERMAN OF "X" AND "YY" 
ACKERMAN OF "X" AND "Y" 
ACKERMAN OF "X" AND "" 
ACKERMAN OF "" AND "Y" 
ACKERMAN RETURNS "YY" 
ACKERMAN RETURNS "YY" 
ACKERMAN OF '"' AND "YY" 
ACKERMAN RETURNS "YYY" 
ACKERMAN RETURNS "YYY" 
ACKERMAN OF "" AND "YYY" 
ACKERMAN RETURNS "YYYY" 
ACKERMAN RETURNS "YYYY" 
ACKERMAN OF "" AND "YYYY" 
ACKERMAN RETURNS "YYYYY" 
ACKERMAN RETURNS "YYYYY" 
ACKERMAN RETURNS "YYYYY" (to PRINT) 
YYYYY 



Fig. 8. Tracing a Logo Procedure's Activity. 



Ackennan's function was chosen because It provides a general 
exercise for Logo's tracing ability. The Logo procedure In Figure 1 
and that used for Figure 4 are not as suitable because they are "last- 
line" recursions. The processes they realize are essentially 
Iterative. They do not make use of the local context which Is saved 
when a new copy of a procedure Is recursively called and the calling 
copy is suspended. In contrast, note the sequences like: 'ACKERMAN 
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RETURNS 'ACKERMAN OF in Figure 8 (generated by the recursive 

calls in line 30) and note the values supplied as arguments for each 
call. In fact, some operations, like Ackerman's function, cannot be 
expressed clearly in iterative fashion and thus are difficult to 
formulate in the syntax of languages (e^g. Basic or Fortran) which do 
not provide for recursively defined algorithms. 

The user can, of course, trace as many procedures as necessary for 
debugging a program. Moreover, debugging during program synthesis is 
facilitated by the line-editing commands like "control-N" that were 
discussed earlier. Since Logo will always execute a direct command, 
even when defining a procedure, the user can cry a number of command 
lines until one has the desired effect, and then he or she can type a 
line number and "control-E'* to copy that .last, workable line into the 
procedure's definition. This is helpful when writing procedures which 
draw or engage in some actions that must be subjected to fine tailoring. 

2.2 Peripheral Devices 

In the following sections we provide information about the various 
terminals and controllable devices available to Logo and Simper students 
both during and after the experiment (Figure 9). We also mention 
examples of how each device can be employed in solutions to posed 
programming problems. On occasion, sample programs are included — the 
reader should refer back to the previous sections if their meaning is 
unclear. In a later section we will evaluate the usefulness of each 
device based upon our experimental observations • 
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PDP-10 Operating System 



mSSS Student System 

/ \ 

Logo Simper 

/ \ \ . 
/ \ \ . 

\ . 



tec'' Sallogo 



\ . \ 

\ . \ 
\ . \ 



Turtle Audio Train Plotter Teletype IMUC^^^ 



. \ 
. \ 



Dotted lines mark connections made after the 1973 summer experiment, 



Fig* 9. Prograoraiing System Structure. 



For communicating with devices like the IMLAC^ \ Train and 
Audio, the machine-language Logo Interpreter was modified to dispatch 
pertinent commands to another program^. Sallogo (Figure 9). This 
program runs as a coroutine (an "Inferior fork" in Tenex terminology) to 
Logo* Logo and Sallogo each possess 256-klloword, virtual memory 
spaces which are Independent except for one shared "page" of 512 words. 
This shared space Is used for the Intercommunication of commands, 
results and error messages. When Logo traps a command to be 
Interpreted by Sallogo (e.g. 'SAY "HELLO"'), It puts the operation code 
and any arguments Into the shared page, starts the Sallogo process, and 
suspends Itself until Sallogo replies and terminates with an appropriate 
response. Hence, Logo's primitive control of special devices is 
realized by Sail procedures. 
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2>2 J Standard Alphanumeric Terminals 

The slow (10-characters-per-second), noisy, reliable and Inexpensive 
Model 33 Teletype^ ^ was the basic means for communicating with Logo 
and Simper for students in three of the experimental groups* In spite 
of Its obvious drawbacks It was In plentiful supply and provided paper 
printout for projects whose results students wanted to take home (e.g. 
posters) . After they had mastered the basic concepts of Logo and 
Simper, students could spend soma time using the more exotic terminals 
and devices as they were available. Some students retained a 
particular liking for teletypes, because the mechanical bedlam generated 
by an operating teletype fascinated them. 

The TEC^^^ is a fast (several hundred characters-per-second) , text- 
oriented, video display with capabilities for cursor positioning and 
line or character insertion and deletion. Because these terminals were 
neither usually available nor centrally located, students used them 
infrequently. However, we will outline several examples of Logo 
programs which exploit the TEC's capabilities (see Table VIII, or 
Appendix 1.1 for a summary of the relevant IMSSS Logo commands). For 
example, one student defined a "TEC-turtle" which Interpreted commands 
similar to the robot and IMLAC line-drawing instructions. His 
turtle was simply an outline in characters. It could rotate in 
multiples of 45 degrees and leave a trail of characters as it moved. 
Another student developed a "twinkling sky" program which randomly 
placed and erased characters on a TEC*s screen* 
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Table .VIII 
IMSSS Logo/TEC ^^^ Commands 



Name Action 

CLEAR erase screen and put cursor in upper left comer 

UP move cursor up one line (with wraparound) 

DOWN move cursor down one line (with wraparound) 

LEFT move cursor left one character (with spiral wraparound) 

RIGHT move cursor right one character (with spiral wraparound) 

HOME put cursor at upper left comer of screen 

MOVEXY put cursor at an absolute screen position (in 80 by 24) 

BLINKON start screen blinking to right of and below cursor 

BLINKOFF terminate blinking region at present cursor position 

BOX type a "box" charac'cer (all character dots on) 

DELETECHAR e'case character on cursor and move rest of line left 

DELETELINE erase line cursor is on and move lower lines up 

ERASEDOWN erase screen to right of and below cursor 

ERASERIGHT erase rest of line to right of cursor 

INSERTCHAR insert a blank character at cursor position 

INSERTLINE Ineert a blank line at cursor position 



The activity cf procedures which manipulate Logo words and 
sentences can be visually seen by writing the procedures so that they 
provide graphic output of internal string machinations. For example, 
students could watch a program move the TEC's cursor from character to 
character as it searched for certain chatacteis which it then deleted 
both from the Logo wcid and the display screen. Elevator (see Appendix 
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1*1) and "drunken walk" simulations were also done. With the TEC 
display, it is possible to produce simple animations of a program's 
activity. 



2.2.2 Vector Graphics Terminals 



From 9:00 AM to 11:00 AM on weekdays, five H^C^ ' PDS-1 vector 
displays were reserved for two of the five experimental groups. The 
PDS-1 is a computer in its own right, but students used it only as a 
"smart" interface to the PDP-10 (see Appendix \.l for details on the 
PDS-1 and on the Logo interface to our graphics system) . The IMLAC- 
graphics line-drawing system was implemented to emulate many abilities 
of the robot turtle developed at MIT and BBN (Feurzeig and Lukas, 
1972b). It lacks the mechanical robot's touch sensors (although these 
could be simulated by graphic constraints), but allows movement to be 
specified by "X,Y" end-points in addition to the turtle's normal, 
roving-polar-coordinates scheme (in which movement is specified by 
'FRONT' and 'BACK' along an angular beading changed by 'RIGHT^ and 
'LEFT'). For example, to draw a square, one might write the following 
Logo procedure: 

TO SQUARE :SIZE: 

10 FRONT :SIZE: 

20 RIGHT 90 

30 FRONT :SIZE: 

40 RIGHT 90 

50 FRONT rSIZE: 

60 RIGHT 90 

70 FRONT :SIZE: 

80 RIGHT 90 

END 



Students can change the IMLAC turtle's appearance with 'SEE', 'HIDE', 

46 

ERIC - ^ 



'POKE* and 'UNPOKE* (see Table IX and Appendix 1.2 for a description of 
IMSSS Logo's turtle-graphics primitives) ♦ The graphics turtle can 
leave a trace ('PENDOWN')^ or not ('PENUP'), as it moves. The last 
lines drawn may be erased by 'ZAP' and 'ZIP' commands, permitting 
limited picture editing as well as primitive animation. For instance, 
one student produced a short sequence showing a fuse "burning" down 
(disappearing into) and exploding a firecracker. 

'plot' allows one to direct the effects of most graphics commands 
to either an HP7202A plotter or a robot turtle. Most students highly 
valued the ability to reproduce on paper what their programs had drawn 
on the display semens. 

During the experiment, it became apparent that more powerful 
animation abilities would be possible and might serve as strong 
motivation for more complex student projects*. At the end of the summer 
experiment, we added genuine animation to Logo (see Table X or Appendix 
1.2 for a description of Logo's animation primitives). By typing 
'SNAP', the student Instructs the graphics system to save the effects of 
all subsequent graphics commands as a display subroutine within the 
IMLAC. 'ENDSNAP' terminates the subroutine. The result is a numbered 
"snapshot" which can be shown anywhere on the IMLAC screen. 'SHOWSNAP' 
shows such a snapshot at the turtle's current screen location. For the 
purposes of erasing (with 'ZAP' or 'ZIP'), a snapshot is equivalent to a 
line segment* Rotation and scaling can be achieved by making several 
snapshots of the same object in different orientations or sizes and then 
showing them successively in a "movie". Thus, a simple recursive 
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Name 

CLEAR 
WIPE 

SEE (HIDE) 
PENDOWN (PENUP) 
PENP 

POKE (UNPOKE) 
HOME 

FRONT (BACK) 
LEFT (RIGHT) 
SETHEADING 
ASETX (ASETY) 

ASETXY 

RSETX (RSETY) 

RSETXY 

THERE 

HERE 

ARC 

ZAP (ZIP) 

PLOT (UNPLOT) 

SETSCALE 

SETTURTLE 

WRAP 

COMPRESS 
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Table IX 

IMSSS Logo Turtle-Graphics Commands 
Action 

erase the text area of the screen 

erase any drawing and put turtle home 

make the turtle appear (disappear) 

enable turtle to draw visible (Invisible) lines 

return "TRUE" If turtle's pen Is down, "FALSE" otherwise 

stick out (pull In) turtle's head 

move turtle to home position defined by SETTURTLE 

move turtle forward (backward) a specific distance 

rotate turtle left (right) specific number of degrees 

point turtle on a specific angular heading 

move turtle horizontally (vertically) to an absolute 
screen position 

move turtle horizontally and vertically to a position 
move turtle horizontally (vertically) a relative amount 
move turtle relative to Its present screen position 
equivalent to an ASETXY and a SETHEADING 
return turtle's current position and angular heading 
make turtle draw an arc of specified radius and sense 
erase last turtle move(s) up to a visible line segment 
(do not) direct turtle commands to robot or plotter 
set screen resolution in unlts-per-lnch 
set both scale and home position on screen 
set up screen boundaries for wraparound 
shorten DCLAC display list (precludes use of ZAP or ZIP) 
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Table X 

IMS5S Logo Animation Commands 



Name 



Action 



SNAP wipe screen and begin creating a numbered "snapshot" of 

whatever drawing (less erasures) Is subsequently done 

ENDSNAP finish defining current snapshot and wipe screen 

ERASESNAP delete specified snap and Its number 

WHATSNAPS return a sentence of currently used snapshot numbers 

SHOWSNAP display specified snapshot at turtle's screen position 

PUTSNAP identify a snapshot with an old or new "object" at a 

specific screen position, or move or erase an object 

MOVESNAP move an object (with wraparound) a relative distance on 

a relative heading and return object's final, absolute 
position 



WIPESNAPS 



wipe screen and erase all snapshots and objects 



procedure for moving an object, referenced by a snapshot ntimber, across 
che screen might be: 

TO WALK :SNAPNIM3ER: 

10 SHOWSNAP rSNAPNUMBER: 

20 ZAP 

30 FRONT 10 

40 WALK rSNAPNUMBERj 

END 



(The reader might try to imagine the scene produced if line 20 were 
omitted) • 



With respect to additions and deletions, the ' SNAP '/' SHOWSNAP ' 
scheme establishes a stack (last-in-firat-out) ordering on the elements 
of a scene* It proved adequate for many simple animation projects, but 



49 

ERIC 



it prevents placing a snapshot independently of the turtle and it 
precludes erasing a particular snaphot without first erasing and then 
restoring all picture elements that were drawn after that snapshot. 
Given the nature of the IMS3S Tenex time-sharing system, this scheme 
usually requires too much time to communicate, from Logo to IMLAC, all 
the data needed for complex yet brisk animations (see also Section 5). 

In order to manipulate snapshot occurrences independently of their 
displayed order, and to reduce intercommunication needs, we provided two 
additional operations. 'PUTSNAP* creates an "object" which is a 
snapshot placed at a particular "X,Y" location on the screen. For 
example: 'PUTSNAP "5 1" "0 0"* associates snapshot 5 with object 1 at 
screen location 0,0. The relative location of this object now can be 
changed with 'MOVESNAP*. The snapshot associated with an object simply 
defines that object^s current appearance. Thus, subsequent 'PUTSNAP* 
commands can change either the appearance or the absolute location of an 
object already on the screen, 

A large saving in ccmmuni:.ation time resulted from this design; 
complex animations became viable even in a normal time-sharing 
environment. The *WALK* program shown above could be rewritten as: 

TO WALK tOBJECTNUMBER: 

10 MOVESNAP tOBJEOTNUMBER: "10 0" 

20 WALK :OBJECTNUMBER: 

END 

Although the animation facilities were not used by students during 
the summer experiment reported upon here, they were used in a later 
experiment (Cannara, 1975'^^ A number of students from the summer 
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experiment continued to work with Logo after school began, influencing 
some aspects of the developing animation system^ A two-minute, black- 
and-white film about Logo/DILAC graphics and animation is available from 
IMSSS. Figure 10 is taken from that film. 

Students used Logo animation to produce such things as a flyable 
helicopter, a rocket launch, animated tic-tac-toe and a movie of 
throbbing polygons. An example program appears in Appendix 1.2. 

A Windmill Simulated with Logo/IMLAC ^^^ Animation 




Fig. 10. Successive Frames from a Logo -Animation '*Movie". 



* We are indebted to Pat Crawley of the Stanford Communications 
Department for producing this film, and to Adam Grosser, Greg 
Hinchliffe and Steve Spurlock for their imaginative programming. 
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2.2.3 Output Devices t Plotter ^ Turtle ^ Train and Audio 

Twice, near the middle and end of the experiment, a Hewlett-Packard 
model 7202A plotter was available to out students. With this device, 
students could produce permanent pictures on paper. This particular 
plotter has a resolution of one part in ten-thousand and directly 
accepts alphanumeric (ASCII) strings for line and point plotting, making 
it an extraordinarily easy device to connect to existing systems. By 
first typing 'PLOT' and an appropriate teletype number to Logo, a 
student can execute almost any Logo-graphics commands with ink on paper. 
Erasing and animation commands (e.g. 'ZAP') have no effect. Students 
can use any tjrpe of terminal and still have their drawings appear on the 
plotter. This can be used to encourage students to write and debug 
storable procedures rather than to just draw by direct Logo commands. 

A robot turtle, music box and their interface (all manufactured by 
General Turtle Inc. of Cambridge, Mass.) also were available to our 
students for several days at the end of the summer experiment, and 
again, during winter and spring — 1973-1974. Like the plotter, the 
robot/music-box interface is straightforward to use because it 
interprets ASCII characters as commands. These devices were not used 
as much in the experiment reported upon here as in the subsequent one, 
80 further details on them are confined to Appendix 2.1. 

(R) 

During winter and spring, 1970-1971, a Marklin^ , HO-gauge, 
electric-train layout was constructed at IMSSS (see also Goldberg, 
Levine and Weyer, 1974). It uses a special interface which decodes 
characters, sent by PDP-10 programs, as commands for setting switches 
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and controlling the train *s motion (see Appendix 2.2). The Interface 
also responds to queries about the presence of cars within a number of 
distinct regions of track (blocks). When controlled by Logo, a Sail 
program (Sallogo In Figure 9) Interprets commands to the train, 
remembers switch states and the train's block and direction, determines 
legal moves, prevents potential derailments, monitors the train's 
motion, and can find a path through any maze of possibly disabled 
switches (or announce that no path exists) . The latter ability was not 
Intended for students to use; students are supposed to write their own 
maze-solving programs. 

In 1971 and 1972, prior to our receipt of BBN Logo, a Basic-like 
language and a small, traditional CAI curriculum were designed for and 
used by students to solve mazes with the train on the fixed layout. A 
schematic picture of the track layout is given in Figure 11. We use 
to separate blocks, which are designated by numeral-letter pairs. 
Slashes ("/" or "\") cross other tracks at switches. Two "crossovers" 
(nonswltches) also exist in Lhe layout (at locations "5B" and "3E") . A 
five minute coicr film, available from IMSSS, documents the project some 
time before Lego was modified co control the train. The Logo/Train 
interface is also detailed in Appendix 2.2 Train commands are 
summarized there and in Table XI, 



* We thank Steve Mylroie for his dedicated work on the hardware. The 
film was produced by Mike Raugh with the help of Marney Beard and 
Jonni Kanerva. 
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Fig. 11. Schematic of the Logo-Controlled Train Layout, 



In retrospect, and for the benefit of those who would also be 
Interested In building this type of device, It Is clear that precipitous 
construction of a fixed layout, any layout. Is likely to be a mistake. 
We should first have graphically simulated the train domain, which in 
fact can now be done with the Logo-animation discussed earlier. Then, 
given the nature of the application, a hardware incarnation could have 
been selected. The existence of a simulation would also have allowed 
our work to continue, even when the hardware failed. Some of the value 
of a concrete, physical device is of course lost in any simulation, but 
the level of hardware reliability required of a real device is often 
underestimated. A model train is a particularly challenging piece of 
equipment in terms of reliability. Desirable abilities such as 
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Table XI 
IMSSS Logo Train Commands 



Name Action 

FRONT move train forward a specific number of blocks 

BACK move train backward a specific number of blocks 

HOME move train to Its starting location (see SETTRAIN) 

TRMOVE find a route and move train to a specific location 

SPEED set the train *s speed 

SETSWITCH set the direction of a specific switch 

SETTRAIN set all switches straight, find train on track and put It 
at a specific starting block 

CONNECT join three specific blocks by throwing appropriate 

switches 

TRAINFO retura Information about the state of a specific block 

or switch 

WHERETO retura a sentence of locations accessible from a 

specific location 

WHERE return a sentence of blocks under and to either side of 

train, and the state of any relevant switches 

TROP general Sallogo operator for communication with Logo 

(used for experimental commands) 



WHISTLE 



blow the train *s whistle 



independent control of multiple trains make heavy demands on any system 
for communicating between Interface and rolling stock (engines and 
cars) . A piece of dirt on the track can wreak havoc with naive train- 
monitoring schemes* 
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One reason why the IMSSS train has not been used extensively is its 
lack of reliability* In addition, the fixed layout and control 
facilities hamper the educational usefulness of the entire system. 
Ideally, students should be able. to design their own layouts from a 
basic matrix by defining allowable connections. Then, problems of a 
g-^aph-theoretic nature could be posed. 

Evaluation of our implementation led us to believe that a 
generally suitable layout/simulation would have switches as nodes in a 
graph whose links are track sections. The switches would not be 
imbedded in blocks, as they are in our present physical layout, and a 
piece of rolling stock would not be allowed to stop on them. Nodes 
would be the center of activities like uncoupling as well as switching. 
In fact, a train simulation along these lines has been produced at 
another research facility by one of the authors. Users of that system 
can design their own cars, draw their own layouts and run as many trains 
as they please. In terms of the relative value of simulation, it is 
worth noting that the aforementioned simulation demanded an amount of 
effort some orders of magnitude less than that expended to build our 
physical system at IMSSS, and it is eminently modifiable. 

Another type of device, which allowed students to make the computer 
"talk", was made accessible via Logo toward the end of the summer 
experiment. It is the digit ized-audio system developed for and used 
by the Stanford reading project (Atkinson, Fletcher, Lindsay, Campbell 
and Barr, 1973). Using the Logo primitive 'SAY', students could make 
the computer utter sounds composed of any of 2000 prerecorded phrases. 
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words, and phonemes stored on a system disc unit* As for most of the 
other devices we have discussed here, the audio system was accessed via 
Sailogo. During the fall of 1973, only one terminal with audio output 
was available to our students, on a limited basis. Nevertheless, 
several students produced guessing games, word games, amusing parodies 
of CAI like the Stanford reading program, narrations with deleted 
expletives, and a truly amazing program that could dial a telephone (via 
a special switchbox interface) and talk to whomever answered. In 
reality we have only added the aural equivalent of 'PRINT* to Logo, but 
when used in conjunction with graphics terminals, for example, students 
can attack problems like the coordination of dialogue and picture in 
movies. One student designed a, talking turtle that narrates its 
drawings. If work with the audio device were to continue, we would 
like to give students the ability to record and access sounds that they 
produce themselves. For the interested reader, an improved audio 
recording and playback scheme is currently under development at IMSSS 
(Benbasset and Sanders, 1973). 

2 Student Selection , Grouping and Tutoring 

Our desire to draw some conclusions about programming languages and 
devices led us to design two linked sub-experiments (Table XII) : 
children using teletypewriters (Groups I, II and III) and children using 
graphic displays (Groups IV and V) . The f ir;3t three groups would 
provide most of the data for comparing the languages, evaluating the 
curricula and characterizing tutor-student-machine interactions. It 
was hoped that comparing the behavior and performance of Groups I and IV 
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Table XII 



Experimental Groups 



Group 



Composition 



I 



8 students learning Logo and then Simper 



II 



8 students learning Simper and then Logo 



III 



8 students learning Logo and Simper at once 



IV 



5 students learning Logo with graphics 



V 



10 paired students learning Logo with graphics 



would suggest what advantages or disadvantages graphics has for novice 
programmers, while Groups IV and V might suggest how well students can 
work In cooperative programming situations. The graphic capabilities 
available to these groups were described In section 2.2. 

Schools within bicycling distance of Stanford were contacted in 
order to obtain inexperienced volunteer programmers, 10- to 15-years 
old — an age which is thought to ensure that children can master 
abstractions (Piaget, 1970). Teachers and others recommending 
students were asked not to base their selections on students* 
performances in school, because we were interested in studying how any 
child learns to program. We had observed previously that teachers tend 
to recommend only their better mathematics students for such special 
projects. Apart from an admonition against such preference, we could 

* We are indebted to Carolyn Stauffer for her invaluable help as 



liaison. 
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not control the way In which the invitation "to learn how to use a 
computer" was presented to students, so we cannot be certain that our 
enrollees constituted a ^rcss-rsection of local students. More students 
responded than were needed for the .groups outlined in Table XII. We 
attempted to accommodate them all, including friends who appeared later 
during the body of the course., Figure 12 presents some information 
supplied by the enrolling students in response to a brief questionnaire. 
Since students typically heard about the course from their mathematics 
teachers, the preferences they ey:pressed weren't surprising* In all, 
about fifty students involved themselves in the course at one time or 
another. To some degree, this insulated the experiment from the 
problem of dropouts. 

One-hour classes were held In the mornings four days-a-week. In 
theory, Fridays were reserved for modifying the carricula and debugging 
the interpreters or devices. Howevex, on demand of some of the more 
interested students, Friday was considered open too. Since we could 
provide no transpottaticn, those students beyond bicycling range were 
transported by chelr parents Parental inability to continue 
rranspcr cation oreaf^id a few defacta dropouts. 

In order to obtain an initial assessment of each student's aptitude 
for programming, and co point out possible problems that each student 
might later have m learning the concepts, we constructed a test 
consisting of questioas gleaned from a wide range of sources. 
Unfortunately, we found no teat in current use which Impressed us as 
being valid loi the range of concepts In Table I. A number of 
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Fig. 12. Some Information Characterizing the Students. 
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commercial programming tests were examined and some questions from 
these were used* However, all these tests relied heavily on timed 
sections of multiple-choice, often repetitious questions ^ Such 
structuring produces easily graded results and is commonly used to boost 
the "reliabilicy" (correlation among test applications) of a test. We 
were inclined to place emphasis on the more elusive but crucial notion 
of validity. 

A test, no macter how reliable, is utterly useless if it falls to 
measure the property of interest. It may even be dangerously 
misleadi^cc. In terms of the theory of testing, as currently applied in 
the social sciences (see Worthen and Sanders, 1973), validity like 
reliability is measured by correlative techniques. However, no matter 
how long the chain of correlations, validity is ultimately founded in 
human judgements and evaluations. While we intend no critique of 
testing theory and practice here, an example from one of the commercial 
test brochures is discussed in Appendix 3.1, It should alert the 
reader to some cf the pitfalls that threaten those who wish to do 
aptitude testing^ particularly with commercially available materials o 
The onl-> c:)nclusloii ve hope to imply with such an example is that 
testing theory and practice typically diverge when validity is demanded, 
and yet validity of measures is precisely what must be demanded wh^a 
meaningful research is the goal. 



* Tests included: the ARCO Computer Programmer, the CPAB and Flanagan 
Industrial Test series by SRA, the ECPI data-processing test, and the 
IBM programming aptitude test. 
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We had two purposes for presenting our new students with a test. 
First, a valid measure of a student *s aptitude for learning the concepts 
would be needed for matched grouping of the students now (as per Table 
XII) and for a later study (Cannara, 1975). Second, we hoped It would 
be possible to match the way students attacked particular questions in 
the test with particular aspects of their performance in the course. 
Thus the test might be able to suggest the sort of tutorial help each 
student would need. The test itself was a subject of research. It 
was constructed of some questions taken from the commercial tests we 
examined and questions of our own design. All questions were 
formulated or reformulated to require constructive answers. A 
definitive portion of the test is reproduced in Appendix 3.2. For our 
purposes, multiple-choice items would be useless. We wanted to know 
what students thought about each question and why they gave their 
answers, even if the answers were wrong or incomplete. Detailed 
answers would help us evaluate the test as well as the students. 
Validation of the test, item by item, student by student, would be 
immediately subjective with no extraneous correlations. 

About one-hundred questions were selected for possible use in the 
test. Before the questions were presented to the incoming students, we 
attempted to evaluate their difficulty and clarity, and the time 
required for their solution. We presented the entire assemblage to 
several programmers (childrei. and adults) in the IMSSS community. As 



* We are grateful to Marney Beard, Doug Danforth, Adele Goldberg, Paul 
Hechinger, Greg Hinchliffe and Lauri Kanerva for their help. 
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a result of this simple evaluaticn, we dec: ied to accept most of the 
questions and present them in two tests* About one-third of the 
questions were presenced to students on the day they enrolled, and were 
to be completed in one hour* The remainder were to be completed at 
home at each student *s convenience. The two parts of the test 
contained many similar questions. This strategy was chosen because the 
preliminary evaluation had suggested that time should not be a factor in 
the test. Thorough and accurate evaluation of both test and students 
seemed to demand that as many questions as possible be answered • The 
two-part testing would also suggest whether or not any time limit should 
be applied to the single test which would be used in the later study. 
Unfortunately, many of rhe students failed to complete the lengthy 
"take-home" portion of the test, either for lack of interest or because 
they left the course. Therefore, most of what we will discuss about 
the test will derive frcm results of the shorter, timed portion. 

We had selected questions according z:^ their apparent value in 
testing the ability t:^ manlpula^:e unfamiliar languages, model or analyze 
processes, fcxm deductions, and visualize flgural transformations. 
Some of the questicns proved to be very useful for discriminating among 
the enrolling students. Two ot these, the "candy-machine" and the 
"number s-in-boxes" problems, required an understanding of concepts 
directly related to programming > Ercors made by the students on these 
two questions were especially irnce testing.. 

One of the questions presented a partial flow-diagram for a candy 
machine (the first problem In Appendix 3.2). A few states had been 



left blank and connections between some states were mijsing. The task 
was to complete the diagram in any reasonable way* Many students had 
trouble with the basic idea that a process can be represented on paper 
as a diagram of the sequence of events in the process. They left blank 
states empty, filled them inappropriately, or mlsconnected the dangling 
states. Errors in the solutions given could be divided into three 
classes: (1) assignment of unreasonable destinations for unconnected 
arrows, (2) assignment of unreasonable functions for undescribed states, 
and (3) treatment of the entire diagram as a maze in which only one path 
was to be marked as a likely protocol. Errors in class (1) or (2) 
suggested that a student had trouble using the information already 
present in the diagram to deduce reasonable "things to do next" or 
"things to do now". Class (3) is interesting because such errors 
indicated that a student viewed the diagram as instructions from which 
to choose one plausible sequence, .rather than as a complete 
description of all possible sequences, for some process. 

The other question (given as the second problem in Appendix 3.2) 
asked the students tc obey a short sequence of arithmetic instructions 
which operated on some numbers in a set of numbered boxes. Very few 
students correctly obeyed the instruction which read: "Add the number 
in box 7 to the number found in the box whose box number is in box 6, 
and write the sum in box 6". The sentence is hard to read, but the 
idea that a number (value) in a box could be used as the number (name) 
of a box (indirect addressing) was the typical difficulty. Many 
students also had trouble with the idea that writing a new number into a 
box should destroy its previous contents. Solutions fell into a few 
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distinct classes which can be attributed to failures In the 
understanding of those two concepts. 

In a later section, we xd.ll discuss the relationship between 
students' solutions to test questions and their performance In the 
course. Our desire for constructive answers to all questions Is best 
justified by those examples of 'Hfrong" answers which nonetheless showed 
that students were thinking along the right lines. Figure 13 presents 
some answers for a question derived from a commercial programming 
aptitude test (note the subtle defects In drawings B and C, and the 
beguiling A-B sequence) . It is Important to note that answers like 
those in the figure evidence approaches to the questions which would 
have been counted completely right or wrong if nonconstructlve answers 
(e.g. multiple-choice) had been required. Figure 14 shows examples of 
totally unexpected answers to a question of our own formulation. One 
can neither assess a student fairly, n^-^ know what a test is testing 
(and therefore cannot begin to establish validity) if the scheme for 
generating answers critically warps or limits any information relevant 
to the purpose test# 

Results of the test were used to establish a rank ordering of the 
enrolling students and then to assign them to experimental Groups I, II 
and III. Performance on the test seemed to break into a few levels, 
and roughly equal numbers of students from each level were assigned to 
the first three gro ns. Groups IV and V were formed according to 
student preferences on working alone or with a partner, so that no one 
would be forced into an uncomfortable situation. Groupings I, II and 
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The Question and the Desired Answer 

Figure A was changed Into Figure B by a simple rule. Please 
draw figure D so that It corresponds to figure C changed by the 
same rule. 





What Is the rule In words? 



BOTTOM SHRINKS, TOP GROWS 



Other Answers 



TURN IT UPSIDE DOWN AND ALTERNATE SIZE 



A IS A SQUARE WITH A CIRCLE, B IS JUST THE OPPOSITE 



YOU CHANGE TO THE OPPOSITES 



TAKE THE FIRST BASIC FIGURE AND CHANGE 
WITH THE SMALLER AND TURN UPSIDE DOV/N 



THE SMALL TOP FIGURE BECOMES LARGE AND THE 
OTHER BECOMES SMALL AND THEY TRADE PLACES 




Fig. 13. Some '"Wrong'* Answers from the Preliminary Test. 



The Question and the Desired Answer 

What one rule, not using arithmetic, was used to make the 
digits on the right from the strings of digits on the lefc? 



999999999 9 

556 5 

6106 6 

TAKE THE FIRST DIGIT 



Alternate , Unforeseen Answers 
PREDOMINANT NUMBER 

WHAT EVER NUMBER THERE IS MOST ON THE LEFT, PUT IT ON THE RIGHT 



TAKE THE DIGIT WITH THE HIGHEST PLACE VAIiUE, 
OR THE ONE THAT REPEATS MOST OFTEN 



Note: "number" was acceptable although "digit" or "numeral" 
were technically correct. More than half of the students who 
gave complete answers to this problem seemed not to be aware of 
the distinction. Their rank and choices of words contrasted 
as: 



"digit" 

student rank or "number" 

"numeral" 

above median 9 8 

below median 3 8 



Fig. 14. Some Novel Answers from the Preliminary Test » 
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Ill were logical rather than physical because the students determined 
their own class schedule within the time constraints mentioned earlier. 
Scheduling of Groups IV and V was constrained to specific times because 
of the limited availability of graphics terminals. 

Figure 15 shows the composition of the groups according to testing 
rank, age and amount of time spent in actual work with the interpreters. 
Notice from the table that the median tends to divide younger (10-12) 
from older (13-15) students. The candy-machine and the "logic" (the 
third problem in Appendix 3.2) problems tended to be most influential in 
discriminating among students of equal age above and below the median. 
The youngest had the most trouble with the candy machine. They missed 
the point that the diagram was an overall description of the machine. 
A few of the older students were familiar with flow-charts from school 
and thought that problem easy. They were also students who arrived 
after the course had begun. Late arrivals usually did very well with 
the test, perhaps in part because they could work on it quietly alone — 
a feature lacking in our massed testing of the first enrollees. 

Examining the test results in terms of four constituents, the first 
three problems in Appendix 3.2 and everything else, we can compare the 
students' performances generally as follows. Students at the bottom 
of the ranking were unable to grasp the candy-machine and the box- 
program questions, they correctly analyzed only the clearest statements 
in the logic problem, and they failed to finish the test by a large 
amount. Students near the middle filled only the empty states in the 
candy machine reasonably; they correctly obeyed all commands but the 
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Group Age Hours Spent Using Logo & Simper 

III*$ 15 36.4 

1$ 15 35,7 

IV 12 23.3 

++ V 13 23.0 

+ II*$ 15 18.1 

+ IV 13 52.6 

+ 111$ 13 29.7 

+ III* 13 11.1 

+ I*$ 12 12.7 

+ II*$ 13 59.2 

+ III// 14 0 

+ I// 14 5.8 

+ II 13 50.6 

++ V* 13 33.4 

II 14 33.5 

II 12 22.8 
IV 11 22.7 

IV// 14 15.6 Legend 

IV 13 19.0 

II// 14 6.4 * marks students who enrolled 

II*// 14 27.9 after the course had begun. 

I// 14 5.7 

I// 14 5.7 + joins graphics partners, 

median.. II// 14 0 

I 11 24.2 . marks significant breaks In 

II// 14 4.9 performance on the test. 

III 11 14.2 

I 12 23,0 // marks those who dropped the 

I 14 18.0 course early. 
Ill*// 13 2 J 

III 12 11.0 $ marks students who continued 

I I 1 1 V// 12 4.7 programming well after the 

1 1 1 I I I V// 10 6.9 course had ended. 

+ + III 13 28.7 

+ + 1$ 12 27.1 

I 1 1 1 1 1 1 1 V 12 18.5 

+ + + ++ V// 11 2.6 

+ + + + I* 10 1 U 7 

+ + + -H-V# 12 13.5 

+ + ++++ V// 12 0.9 

+ + II ..12 21.1 

+ + 111 12 20.1 

+ + I 12 19.1 

+ 1 1 1 1 1 I Vi9 12 9.4 

+ 111$ 10 35.7 

+ IV$ 11 41.8 

I 1 1 1 1 Ml V 11 25.0 

II 13 6.1 



Fig. 15. Student Ranking on the Preliminary Test. 
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the indirect-addressing command in the box program, with some failures 
to erase a box's content when they wrote into it; they only missed the 
fourth statement in the logic problem; and they did FalCrTjrwell on the^ 
rest of the test, though not always finishing it. Students near the 
top correctly filled all states and connected all the dangling arrows in 
the candy machine, a few of them missed the indirect-addressing command 
in the box program, they did the logic problem correctly, and they 
typically finished the rest of the test. Of course this breakdown is 
not rigid. In particular, it is very hard to order many of the tests 
in the broad middle region of the ranking. Ranking forces transitivity 
upon performance ratings for solutions and problems which are often 
qualitatively different. But, however difficult our work was made by 
demanding constructive answers, the answers contained maximal 
information about the students and the test. If the test had been an 
exercise in multiple-choice, it is not clear what it would have told us, 
but it certainly would have told us less. Suggested changes in the 
test will be discussed later, as part of the experimental results. 

We planned chat the experiment depend upon written curricula which 
would control the basic information given to students. Interpreters 
for the programming languages would simply act as computational 
resources which the students could use to work problems in the curricula 
or experiment with on their own. However, we felt it was impossible to 
develop a fully self-contained curriculum for programming* In 
addition, our main concerns were gaining access to tutorial protocols 
generated by novice programmers while trying to give the students the 
best possible environment for learning. Therefore, we decided to 
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provide human tutors who could help students over failures in the 
curricula and report to us on their interactions* The tutors were to 
be knowledgeable in the programming languages being taught and would be 
familiar with the corresponding curricula* We hoped to have enough 
tutors available each day to guarantee at least one for each five 
students in each group. We emphasized two instructions to the 
tutors: (1) never type anything for the student on his or her own 
terminal, even when giving the most direct help, all typing must be the 
student *s; and (2) when asked for help on any problem, encourage the 
student to formulate and try out his or her own ideas first, before 
making other suggestions* We hoped these instructions would guarantee 
the purity of the protocol data and help the students to think as much 
about generating and debugging ideas as about getting correct results* 
An evaluation of the tutoring effort will be included in our discussion 
of results* 

^ Curricula 

Development of "parallel" curricula for Simper and Logo proved to 
be the most demanding task in setting up the experiment* Both the 
concepts and the languages had to be taught, and this is done best with 
example problems, some of whose solutions students must copy, modify or 
generate* We felt our ability to teach both the concepts and the 
languages would be very sensitive to our choice of problems. And, for 



* Out thanks go to Avron Barr, Marney Beard, Doug Danforth, Adele 
Goldberg, David Rogosa and John Shoch for their help as tutors 
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our students, we hoped that the course would serve to improve their 
literacy on the subject of computers and computation • Again our choice 
of examples and projects would be important • 

Unfortunately, documentation of problems used in similar work by 
others was scatce or cursory. Furthermore, most of the relevant 
research had been based on Logo or an equivalent high-level language. 
Problems appropriate for a low-level language such as Simper are 
typically quite different. That was the fundamental obstacle to 
achieving apparent parallelism, given the intentionally diverse natures 
of the languages to be taught. So, the curricula were constructed to 
teach the concepts in roughly the same order, using whatever features 
each language possessed that could best be exploited for each concept. 

As well as the concepts, the mechanical details of each language 
had to be taught. A few features (line-editing) of Simper and Logo are 
very similar and were taught at the same time in the same way. But 
most features were taught differently, either because they were 
appropriate to different concepts or because they were needed at 
different times as tools in the general structure of each language. 
Appendices 4 and 5 supply glimpses of the Logo and Simper curricula as 
they were during the experiment. The Appendices and the discussion in 
this section do not reflect the. changes to Logo, Simper and the 
curricula which resulLed from th, ."^.xperiment . 

Each curriculum was divided into logical parts (10 for Logo, 13 for 
Simper) , each typically discussing more than one concept (Table XIII) . 
Typically, these parts gave students programs to work on and fill-in- 
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Table XIII 

Discussions of the Concepts In the Curricula 



Concept 


Logo Part 


Simper Part 


machine command language 


1, 2 




2 


alterable memory 


2, 4, 5 


2, 


J, 8 


literal 


3 


3 




names and values 


4 


3, 


8 


evaluation, substitution 


4, 5 


3, 


5 


stored program execution 


5 


3, 


4 


decisions 


8 


5, 


12 


pro cedures 


5 


8, 


1 1 


procedure arguments 


6, 7 


7. 


11 


functions 


6 


7. 


8 


composition 


6, 7 


7 




partial/total functions 


7 


7 




context 


4, 6 


5, 


11 


changing context 


7 


11 




recursion. Iteration 


5, 7, 8 


4. 


9. 11. 12. 



the-blanks questions to answer. The parts were distributed one at a 
time, giving the tutors a chance to review each student's work on them. 
Those students learning Simper and Logo simultaneously (group III, Table 
XII) alternately received parts for each language. The concepts were 
presented roughly In the order of Table I. The -joncept of a heuristic 
was Introduced via a scheme for thinking about recursive algorithms 
(Polya, 1957). This Involved a brief case analysis of some problems: 
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(a) what case can be computed? (b) how do I detect that case? (c) if not 
that case, then how do I generate one closer to it? (d) what must I 
remember for each case? and (e) when do I stop? In procedural terms, 
(a) and (b) form the procedure body, (c) ±3 the recursive step, (d) 
preserves local context, and (e) is the stopping rule. 

A special effort was made to produce visually pleasing curricula • 
Path pointers gave direction to the student, making the next question or 
instruction contingent upon the student *s latest response. This subtly 
introduced decision making and sequencing (program control) . Cartoons 
and examples were chosen for humorous as well as conceptual merit, and 
frequent summaries were included so that the curricula could endure as 
reference material. Outlines of both curricula follow. Occasionally, 
it may be helpful to refer back to Sections 2.1 and 2.2 for details 
concerning the languages and devices. 

Part 1 of the Logo and Simper curricula were identical and began 
with an informal discussion of Churches thesis and how it relates the 
potentials of human thought and machine computation. Some interesting 
capabilities of computers were illustrated. Part 2 used line-editing 
to illustrate that a machine can possess a memory that is alterable via 
commands in a simple, definitely nonhuman language. The substance of 
this part differed between the languages only to the extent that Logo 
has more line-editing commands (see Table V) . Students were oncouraged 
to type anything they desired, in order to test the very primitive error 
handling of the interpreters ^ The incompetence of many of the 
responses so gener^.ted was exploited to help students understand why 
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present machines do not comprehend hiaman languages (because humans do 
not yet understand how language Is comprehended) , and to tie this to 
Churches thesis and thinking In general. 

From part 3 onward, the techniques for Introducing concepts with 
Simper and Logo diverged. In the next subsections, we will discuss the 
remainder of the Logo curriculum, then that of Simper, and finally some 
differences between the two curricula. 

4 . 1 Logo 

Part 3 described Logo's literals (numerals and quoted strings) and 
the simple commands: 'PRINT' and 'TIME'. Turtle graphics students 
(groups IV and V) also tried simple graphics commands like: 'FRONT', 
*LEFT' and 'PENDOWN'. This Introduced Logo's lef t-to-rlght sequence of 
evaJuatlon, as well as commands that return values. Part 4 dealt with 
name/value pairs, assigning to and finding values of names using either 
'MAKE' and 'THING OF', or the colon notation (e.g. ':NAME:'). It ended 
with a short play which illustrated, via dialog, how a command composed 
of several operations and inputs is evaluated by Logo. 

Part 5 directed students to copy and alter a procedure, 'RECTANGLE* 

(R) 

(which drew (printed^ on Teletypes ^) a picture of a rectangle and 
vhich students enjoyed modifying t^) draw a variety of other pictures, 
some censorable) . The part preseated an example procedure, 
'TWORECTANGLES', that called on 'RECTANGLE' twice. Students in the 
graphics groups studied the same examples and solved many of the same 
scring-Oi.iented problems as the other students, but they also worked on 

75 



procedures for drawing pictures ♦ This exercised many of the concepts. 
We did not develop a truly separate graphics curriculum because the 
turtle domain does not provide many novel (in cernis of the concepts) 
uses either for recursive procedures that return values or for 
conditionals — beyond stopping rules for recursive drawings. Flow of 
procedure control was Introduced in this part, as was simple recursion 
(the 'RECTANGLE' procedure calling itself). 

Part 6 presented procedures with Inputs and an output, the use of 
the 'TRACE' command tor debugging, and analogies between procedures and 
functions with respect to composition and Inverses — for example, the 
two procedures: 

TO DOUBLE : NUMBER: and TO UNDOUBLE : NUMBER: 

10 OUTPUT SUM : NUMBER: : NUMBER: 10 OUTPUT QUOTIENT : NUMBER: 2 

END END 

which are nearly mutual Inverses. Because 'UNDOUBLE' cannot handle odd 
numbers, it was cited as an example of a partial function on the 
integers. At this pcint, students had been exposed to sufficiently 
many concepts to be able to create significantly complex programs and 
make interest J ig (to us) errors. 

Part 7 treated procedures which dealt with Logo's basic data- 
structure: strings. The following procedure was one correct solution 
to a problem derivt^d from the preliminary test: 

TO SWITCH 13 :rEXT: 

10 OUTPUT WORD THIRD :TEXT: WORD SECOND :TEXT: 

WORD FIRST :TEXT: BUTFIRST BUTFIRST BUTFIRST :TEXT: 
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— it flips the first and third letters of an input word (procedures 
^SECOND* and ^THIRD* had already been written as exercises). The 
solution served as an example of a function that is its own inverse. 
At the end of part 7, recursive procedure calls were presented as 
sequences of "little brothers" (Feurzeig et al., 1969; Brown and 
Rubinstein, 1973) with "knowledge clouds" describing their local 
environments. Students who were not helped by this were asked to 
consider a chain telephone call as an alternate analogy. 

Part 8 dealt with decision making and the use of predicates, 
particularly in stopping rules for recursive procedures. It posed 
the following model of recursion: 



TO CHOblP rWORD: JSHOMP "TAR" 

10 TEST EI'IPTYP :WORD: TAR 

20 IFTRUE STOP AR 

30 PRINT :WORD: R 

40 CHOMP BUTFIRST :WORD: R 

50 PRINT :WORD: AR 

END TAR 



This model was chosen because it is not a "last-line" recursion (i.e. 
the recursive call on line 40 is followed by an affective command rather 
than by a stop) and requires the student to do some thinking about the 
state of the formal parameter (i.e. the value associated with "WORD" for 
each recursive call) . The last parts of the Logo curriculum 
concentrated on problems to solve and projects to work on which required 
application of all the concepts. The nature and extent of difficulty 
students had with such projects could be used to judge the effectiveness 
of the Logo curriculum itself. 
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4>2 Simper 

Part 3 of the Simper curriculum Introduced the literals of the 
Simper language: decimal numerals. Names and values In machine 
language terms were also Introduced. The part discussed the concept 
that a stored list of values Is a program when It is executed by a 
machine for which those values have meaning. Part 4 motivated the 
sequential execution of instructions. Editing of memory locations 
illustrated another approach to the concept of alterable memory. 
Program control was introduced by a program which subverted (by writing 
into the program counter: register "P") the normal execution sequence. 
The program ran indefinitely. 

That program was exploited further to illustrate the fact that the 
same algorithm often can be realized in more than one way. For 
example : 



are computationally equivalent. The students enjoyed programs which 
ran on and on. A debugging feature in Simper allowed them to display 
registers and instructions as their programs were executed. 

Part 5 attempted to clarify the three-level structure of Simper by 
contrasting the syntax and semantics of interpreter commands, assembler 
instructions and machine ins^ructionso This would be a good place to 
treat the notion of computational context, since many students had 
trouble undei standing that differing languages had to be used for 



001 :PUT A 73 

002 :PUT P 2 

003 :HALT 



and 



001 :PUT A 73 

002 : SUBTRACT P 3 

003 :1 
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communicating with the separate levels of Simper *s structure • The part 
also Introduced the decision-making operation: *JUMP*, and the notion 
of a program bug. The *JUMP* operation offered a good test of a 
student *s ability to predict what a given program would do. Students 
were encouraged to debug by pretending to be the Simper machine (see 
Berry, 1964). For particularly confused students, an egg-carton model 
rf? Simper *s memory and registers proved helpful. 

Part 6 classified Simper *s assembly language Instructions with 
respect to format and use. Special operations, such as *ROTATE\ were 
treated In detail, and new Interpreter commands were Introduced. The 
part acted primarily as a reference manual for operations and ASCII 
character codes. Part 7 reviewed the three essential characteristics 
of a computer (sufficient Instruction set, accessible memory, 
controllable execution) . The concept of a function was Introduced 
using the character Input/output Instructions (I.e. *CASK\ ^CWRITE*) 
which fxansform keyboard characters to/from decimal codes. This 
simultaneously Introduced a new literal, the keyboard character, and the 
Idea of computational context. Students seemed to have a lot of 
trouble grasping the latter. 

The concept of functional composition and Inverse followed 
naturally with a program which used the "B" register to link Simper 
operations which are mutual Inverses: 



001 :CASK B 

002 :CWRITE B 



Concepts of symmetry and domain could be Introduced here because the 
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above program cannot be executed backwards ~ 'CWRITE' does not produce 
an output which is accessible to 'CASK'. 

Students next worked on a program which realized a more complicated 
function (i.e.: X + X + 9), which was derived from the preliminary 
aptitude test. Partial functions were introduced using the 'ASK' 
operation, which accepts only numerals from the keyboard. The concept 
of a data structure was also provided by the character input /output 
operations, and by testing for arithmetic overflow or truncation. The 
latter could be exploited to illustrate non-determinism. 

Part 8 introduced symbolic addresses (names) for memory locations. 
It pointed out that a name can be chosen to reflect the content of a 
location, making it easier to remember the name/value pair (but one 
student insisted that numerals were easier to recall). Students were 
asked to find an alternate realization for the function of the previous 
part (e.g.: 2X + 9) using names and, upon success, to synthesize a 
program that realized some function of their own choosing. Part 9 
introduced relative addressing and data defined by a program which 
rotated five character codes into a single memory word. An inverse 
program rotated the codes back out, typing them on the terminal. 
Students enjoyed using these programs together to read in and print out 
some short words; and iome, who were also Logo users, felt a new 
appreciation for Logo's facility with strings. This type of program 
offered many interesting debugging opportunities. 

Part 10 dealt with indirect addressing, demonstrating again that 
the meaning of data depends on how and by whom it is used. A program 
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which destroyed Itself by decrementing an address used for storing was 
exploited to prove that the Instructions understood by the underlying 
machine are simply numerals (the program could read Its own Instruction 
codes from the student, write them over Itself, and keep on running). 
Indirect addressing was also used In a program that read a substitution 
code from the terminal and then translated '^secret'* messages. This 
helped to clarify what addresses are, it showed that programs and data 
are often segregated, and it Introduced the "array" data-structure. 

Part 11 formally Introduced procedures and their calling sequences. 
Part 12 Introduced stopping rules In au Iterative procedure for typing 
dashed lines of any length. Part 13 merge^ J\e major programs in parts 
9 and 12 into two linked procedures in order to define a new data 
structure: strings (the procedure was called "TYPE" in direct analogy 
to Logons equivalent command). Students could load character codes 
into memory and print them out, thus making such things as posters 
possible, albeit tedious. Students were then asked to synthesize a 
procedure which created, anywhere in memory, a string typed from the 
keyboard. The final Simper part dealt with an implementation of 
recursive procedures using a pushdo^^m stack to preserve local context . 
In the actual experiment, very few students reached this point. 

4.3 Contrasts 

The curricula (and the tutoring) were intended to teach computer 
literacy, especially in the seaoe that the computer is a very general 
tool for solving problems and that numerical processing has little to do 
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with the principles of computation. The Logo and Simper curricula 
were, at least for this experiment, experimental. Ultimately, 
parallelism was sacrificed in favor of presenting the concepts via 
widely ranging applications of various features of the respective 
languages. Furthermore, pieces of the curricula were often synthesized 
"on the fly" if we found that what we had already written was not 
succeeding with the students. 

Part 3 of both the Logo and Simper curricula opened by discussing 
the concept of a literal (numerals in Simper, quoted strings or numerals 
in Logo), but soon diverged. Simper students were taught that a 
machine's memory can be modifiable and observable, and that a set of 
values entered into it can be obeyed as instructions (a stored program). 
They necessarily were introduced to the Simper computer's structure of 
registers and memory. Bits of assembly and machine language were 
introduced along with a few interpreter commands (e.g. 'LIST'). Logo 
students, however, were not exposed to stored programming uiitil Part 5. 
Here, they composed direct commands from simple operations (e.g. 'WORD') 
and literals, thus learning about Logo's string-oriented processing and 
learning that operations can pass messages among themselves. The 
concept of machine memory was treated only in terms of line-editing. 

Logo Part 4 introduced name/value associations (via 'MAKE'), noise 
words, and a fill-in-the-blanks play which reviewed Logo's evaluation of 
a command composed of the faw operations known so far to the students. 
Use of a value as a name (indirect addressing) was also introduced. 
For Simper, this was not discussed until Part 10, although name/value 
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associations had been treated in Part 3* Simper Part 4 continued with 
the basics of programs, attempting to motivate the default order of 
execution (successor) and the ability to override it (by modifying the 
"P" register's content)* 

Simper Part 5 opened by attempting to clarify the tasks handled by 
Simper's three agents: the interpreter, the assembler and the machine • 
The students were asked to classify phrases in each of the corresponding 
languages. In spite of the slightly different interactions which are 
appropriate to command mode versus editing mode, this type of thing was 
not done for Logo, The Simper part also introduced decision-making in 
program control (using 'JUMP') and the idea of a "bug" (an unforseen 
error) which, in this case, caused a program to run forever. 

For Logo, most decision-making was delayed until Part & and bugs 
were discussed first in Part 6. Logo Part 5 introduced procedures as 
both stored programs and new commands. Program control (In the sense 
of sequential procedure calls), program structure and simple recursion 
were motivated by drawing (or printing) multiple rectangles. The part 
ended with a rather complicated procedure that casually introduced 
decision-making to evaluate responses to a riddle. A short manual of 
commands and abbreviations, and a discussion of Logo's program-saving 
facilities were also included. Saving programs in files was now 
important to Logo students because they could write procedures that 
produced desirable results (pictures, etc.). Simper students would be 
introduced to program saving much later, when they could synthesize the 
relatively more complicated machine-language programs needed to produce 
comparable results* 

83 



Logo Part 6 began by discussing bugs and debugging and led Into 
functions^ Inverses and composition* 'TRACE' was Introduced as a 
way of spying on a procedure's true activity. Corresponding use of 
'RUN' and the "ENTER" key had been made In Simper Part 3. Students 
were asked to synthesize and debug their own functions. Functions were 
not similarly treated in Simper until Part 7. Simper Part 6 began vrith 
a brief manual of machine operations and the ASCII character codes for 
future reference. It attempted to clarify the structure of assembly 
language for exceptional operations like 'SHIFT'. This led naturally 
into non-numerical processing of data. In contrast, Logo students 
began with such processing and did the most with numbers later, in Part 
6. The part ended with a brief test of the students' understanding of 
Simper's tripartite structure, which had been observed to be 
particularly confusing to students. 

Simper Part 7 reviewed Church's thesis in terms of the properties 
that a machine must possess if it is to be a computer. The Simper 
machine's characteristics were mapped onto this framework. Functions 
and related concepts were treated using character processing and the 
same visual analogies applied in Logo Part 6. Now Simper students were 
asked to synthesize their own functions. By ma.king an inconsequential 
change to one function, they also saw that a function may be realized 
by more than one algorithm. The part ended by demonstrating the effect 
of finite word-length on the storage and processing of data (i.e., the 
effects of truncation and overflow on numerical data) . Logo Part 7 
paralleled the Simper discussion of computers. It then diverged and 
attempted to motivate the use of Inputs to procedures by introducing new 
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Logo commands (e.g. 'BUTFIRST') and by suggesting several string- 
processing functions for students to write (e.g. 'SWITCH13*). A few 
"block and arrow" diagrams (flowcharts) weire Included to check the 
students* mastery of Logo's command evaluation and procedure execution. 
This type of aid was not used much In Simper. Logo Part 7 also 
suggested that a problem's solution could be structured by writing and 
then combining procedures which solve parts of the overall problem. 
This occurred much later in Simper (Part 11). The Logo part ended by 
discussing recursion again, using the "little-brothers" analogy, with 
and without inputs. The students were asked to synthesize a few 
recursive procedures, which proved to be a difficult task. 

Logo Part 8 introduced de.'lsion making via the use of predicates 
and execution selectors (e.g. 'TEST' and 'IFTRUE'). 'PIGLATIN' and 
*BINAR* (binary Game of Life) were exemplary applications. The use of 
decision-making in stopping rules for recursive procedures was also 
covered (e.,g* 'CHOMP'). Simple, analogous applicc^lons of 'JUMP' had 
been made in Simper Part 5, but stopping rules only became Important in 
the final Simper parts. Simper Part 8 introduced assembler symbols 
(names) for the purpose of making programs more readable. It also 
asked students to write more examples of functions and showed how bugs 
may appear even when applying simple arithmetic operations (e.g. 
division by zero). The latter was analogous to the treatment of 
'DOUBLE' and 'UNDOUBLE' in Logo Part 6. 

Simper Part 9 was concerned with further details of assembly- 
language addressing* It also introduced novel data-structures (e.g. 
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10-digit numerals as 5-letter words) by applying simple manipulations 
(evg. 'ROTATE' and 'LOR'). Strange data-representation schemes were 
not discussed in Logc. Logo Pare 9 continued to provide examples of 
recursive, string-manipulating procedures. 'MEMBERP' provided an 
example of how built-in data-structures could be exploited to represent 
special kinds of information, in this case sentences or words were 
viewed as sets. Along the same lines, students learned how to write 
procedures that could make letters print themselves as posters (using 
'DO'); this was a response to obvious desires of most students. A 
similar concession was made in Simper Part 11* 

Logo Part 10 consisted of many problems that could be solved by 
writing one or two recursive procedures-, Students were encouraged to 
apply previously written procedures as tools (e.g. to use 'REVERSE' in 
writing a palindrome tesfr). A Morse-code problem analogous to one 
done in the same Simper part, and a graphics command interpreter for the 
turtle, extended the idea that the meaning of a message is ultimately 
defined by the recipient c Simper Part 10 introduced indirect 
addressing along with a potentially self -destructive program to carry 
the same point Logo students knew just enough at this time to face 
the rather hard problems of Part 10. The Logo curriculum terjiinated 
here to allow students time to work on the part and on problems of their 
oim choosing. Afterwards, interested Logo students could learn Simper. 

The remaining Simper parts (11 through 13) attempted to motivate 
the use of procedures in machine-code programs, and to show how the 
equivalent of recursive Logo pro:.edures with stopping rules could be 
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realized in Simper* Hopefully from this, students would gain some 
appreciation for the inner structure of Logo and other high-level 
languages. Then Simper students could start learning Logo. The Logo 
curriculum did not discuss the structure of Logo itself. 



5^ Data Acquisition and Analysis 

First, we will outline the simple methods we chose for obtaining 
data, given the experimental setup already described. Second, we will 
mention some features of the IMSSS time-sharing system which have had a 
negative influence on data acquisition or other aspects of this 
experiment. And third we will discuss the type of analysis we feel is 
appropriate for our essentially qualitative study and why that analysis 
cannot be founded naively upon classical statistical inference. 

Throughout the experiment, the Simper and Logo interpreters saved 
information on each student's activities. Each command or response 
typed by a student was appended to his or her individual protocol file 
on the operating system's disc storage. Prompts 'ad error messages 
elicited from the interpreters, and output from students' programs were 
also saved as they happened. Each such piece of information was tagged 
with its time of occurrence. From these files we intended to 
reconstruct each student's interaction with the languages and devices 
he or she used. At the end of the experiment, we modified the Logo and 
Simper interpreters to accept these files directly, in place of keyboard 
input. Each student's interactions with the interpreters could thus be 
replayed and be observed in their proper context. In addition, the 
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error-message and timing data in the protocol files could be analyzed in 
more conventional ways by forming summary statistics such as error 
frequencies and typing delays (response latencies). This sort of data 
was not of particular interest to us except insofar as it could be used 
to point out particularly common errors, or confusions due to 
imperfections in the curricula or the tutoring. Some additional data 
were obtained from notes made by the tutors during the course of the 
experiment. However, as we will discuss later, the tutors were usually 
overburdened and were able to supply only a few corments on their 
interactions with the students. So, the bulk of the data from which 
results can be reported derives from replaying the automatically 
recorded protocols and recording our own work as tutors. 

System Effects . Each day during the experiment, about forty 
students used the Logo and Simper interpreters. At any instant of 
time, between ten and fifteen students would be working. Ultimately, 
their interaction with the interpreters and our ability to obtain data 
were controlled by the operating system implemented on the IMSSS PDF- 10. 
At this writing, that system is Tenex 1.31; during the experiment, it 
was Tenex 1.28, an earlier version. The Tenex system was developed at 
Bolt, Beranek & Newman Inc. of Boston under a U.S. Department of Defense 
ARPA contract to provide "virtual" me^nory management and other features 
to owners of PDP-10 machines. It is historically related to the SDS- 
940 time-sharing system. Certain aspects of the Tenex system, in 
either version, are at once elegant and troublesome. Some others are 
either misleadingly implemented, or logically consequent to the 
philosophy of the system's design yet implemented partially or not at 
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all. We will discuss some examples. Only a few had detectable impact 
on the experiment. Our purpose is documentary — for others who may 
use the same sort of system for similar -purposes. The least 
significant system difficulties appear first. 

(1) A few Logo and Simper operations (i.e. 'WAIT* and 'WAITM') have 
misleadingly inaccurate effect due to the nature of Tenex's program- 
scheduling algorithm. For example, the Logo comand: '*WAITM 60" may 
produce an execution delay ranging from sixty milliseconds to several 
seconds, depending upon the shore-term system load. Unlike operating 
systems typically supplied by the PDP-10's manufacturer, Tenex does not 
advantageously reschedule programs which have dismissed their execution. 
Thus, from a program's point of view, a dismissal interval can be 
specified only by a nondeterministic lower bound. 

(2) Also pertinent co scheduling, and relevant only to our design 
of the Logo/Sailogo system for operating various devices, are delays 
imposed by inter-"f ork" communication. Tenex forks are pseudo- 
parallel, superior /inferior program contexts which may be set up as 
parts of one user's job. Each job is allowed a maximum slice of 
processor time whenever it is ready to run. Thus Logo and Sailogo 
communicate and run sequentially, but as one job. One might therefore 
expect that any time remaining in a Logo job's .xme-slice, after Logo 
has sent a message to Sailogo, would be available to Sailogo to carry on 
the computation. This is not so, because Tenex considers such fork 
communication as an input-output wait and reschedules the Sailogo fork. 
The same is true for :.ommunication In the reverse direction. Depending 
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upon the Instantaneous system load, such ^'Invisible" rescheduling can 
cause abnormally long delays even In simple Logo/Sallogo interactions • 
In our experiment, this effect was -most seriously felt when students 
were doing turtle-graphics drawing and animating. For instance, after 
the experiment, when Simper was modified to contain, in the same fork, 
the graphics portion of Sailogo (easily possible because both Simper and 
Sailogo are Sail programs). Simper produced turtle dravings roughly 
twice as quickly as did Logo. 

(3) Another problem arose when we attempted to simulate the control 
of one device by more than one student. The real train could only 
operate one engine and respond to only one controlling program, so we 
attempted to create a situation in which at least two students could 
interact with a single;, multiple-train layout in a cooperative problem- 
solving situation. The most straightforward design should be the 
linking of rwo Logo jobs to the same simulation by reading from and 
writing into one anocher's memory space. One of the allegedly elegant 
features of Tenex is that every information handling entity in the 
system mimics the behavior of a file (even terminals are viewed as 
readable/writable files). However, one user's job cannot access 
another's fast-memory space, although jobs can share and communicate 
(more slowly) via disc -storage files. Thus forced to design a one-job, 
multi-fork simulation (one Logo fork per user, with the main simulation 
controlled by a superior fork) , we found that Tenex would not allow 
multiple primary terminals for one job. The pseudo-intarrupt system 
required by Logo (e^g. to allow "control-G" to function) could not be 
enabled for more than one atudent user. Success mighc be achieved by 
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someone more familiar with the bowels of Tenex, but we and the system- 
maintenance staff at IMSSS failed. Therefore, we could noc make the 
multiple-train simulation part of our experiment. 

(4) The nature of Tenex's disc-file management influenced our 
ability to save individoal protocols ♦ Given the number of students 
enrolled in our course, we had to maintain at least one-hundred distinct 
files for immediate access by Logo and somewhat more for Simper, 
Typically, half of these were protocols, the remainder student programs. 
Unfortunately, Tenex 1.28 provided for a maximum of about 120 files per 
directory — when a directory is full no new files can he created until 
some are expunged. In such a circumstance, no new protocols and no new 
student programs could be saved. We considered saving all protocols on 
one file; this would greatly reduce the chances of saturating a Tenex 
directory^ The idea was to append data continuously, in what is termed 
"thawed access". This simply means that more than one user may write 
or read the same file. However, thawed access proved useless because 
only data for the last student tc close such a file would indeed be 
saved. To car knowledge, this potentially useful feature has yet to be 
correctly implemented in sny version of Tenex. The present version 
(1.31) at IMSSo eases the directory saturation problem because it almost 
doubles the allowed directory space. However, a more elegant solution, 
based upon the dynaml: directory allocation schemes of earlier PDP-10 
systems, wculd ofier permanent relief. A related difficulty seems from 
the lack of full "device-independent 10" in Tenex. One cannot randomly 
pick two system devices (e>g* a DECTAPE and a standard magnetic tape) 
and send data unifonnly from one to the other. Only some connections 
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can be made without recourse to special programs ^ This only Influenced 
our weekly saving ot student data, for which a special program was used 
to create directories and write files onto standard magnetic tapes. 
Again, this is an example of an effort which would have been unnecessary 
had Tenex's designers incorporated certain important abilities of 
earlier PDP-10 operating systems < 

(5) Our final comments pertain as much to what the IMSSS time- 
sharing system must do, and should be, as to what Tenex is. The nature 
of a "demand-paging" system such as Tenex is to break all programs (and 
files) into uniform "pages" (blocks) of information. Since today's 
computer technology puts a premium price on fast memory, most systems, 
including that at IMSSS, have insufficient resources to allow all 
active programs to reside in fast memory. Thus a paging system uses 
not-so-fast, inexpensive backup-storage to expand a machine's apparent 
memory space. Each usex has virtually the machine *s entire memory to 
work wich, bat is subjected tc transfer delays and rescheduling whenever 
his or her program demands access to pages not in fast memory. 
Theoretically, this allcws diverse uses of the machine in an efficient, 
time-sharing mode (see Denning, 1970^. However, at IMSSS, the bulk of 
daytime ccmpuratlon has been in shared (reentrant) programs. For 
example, students using Logo share large blocks of the interpreter. 
Only data pertinent zo each student varies. Yet, in busy periods when 
many users demand memory, a paging system like Tenex swaps onto backup 
storage even the frequently used shared pages of student programs. The 
fact that even the smallest, one-page programs undergo such blind 
shuttling ac:ounted ior some of the poor performance of Tenex when it 
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was first implemented at IMSSS and .was confronted with loads, typical of 
CAI, generated by scores of students all running In a few, small 
programs. For our experiment (even more so for traditional CAI), It 
would have been useful to have been able to "lock" small, reentrant 
programs into fast memory, thus reducing the paging load while i-surplng 
a relatively small fraction of available memory. Such an option is not 
conveniently available in Tenex (It is under belated study at IMSSS) . 
It should certainly be considered by anyone intending to use analogous 
paging systems for simple educational programming loads in which fast 
response to interactions is paramount. As did the train, Tenex became 
a "fait accompli" at IMSSS without a deep concern for, or a thorough 
preliminary analysis of, its real-life behavior x, 

These comments have concerned aberrations in the IMSSS time-sharing 
system which might influence the service students receive as they work. 
Hardware prcblems, mainly stemming from parity errors in the relatively 
unreliable memory in use (to this date) at IMSSS, also affect its usprs. 
No system can always recover from such errors and often must be 
reloaded, destroying all users' programming contexts. Some data were 
lost in this way, and, more seriously, many students lost theit 
programs, twenty or so minutes of their sessions and their rhythm with 
the curricula* Other problems, which do not generally affect student 
activities, will not be mentioned heie. In general, only (2), (4) and 
the memory errors mentioned above presented dally nuisances to our 
experiment . 
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Analysis * The stated purpose of this experitaent turns upon our 
ability to understand our students as they have tried to learn Logo, 
Simper and the concepts explained in the curricula. We are not 
concerned with classical hypothesis testing, although others have 
attempted to reduce their analyses of children learning programming to 
clinical forms, e.g. 

"Children who have had a Logo experience for several 
semesters will perform significantly better on problem 
solving tasks than children who have been in a non-LOGO 
control environment. 

Scores on a test for recursion in daily communication by 
children who have had a LOGO experience for several 
semesters will be related to their ability to use recursion 
in LOGO programming." (Folk et al, 1973) 

Our goal has been the exposure of basic features of how children 
think in the relatively unconstrained environment of a programming 
laboratory. That is a qualitative exercise, and it centers on a 
detailed study of errors made by students as they try out new ideas for 
themselves. But, an analysis of errors must be valid in the sense that 
the essence of theii pr:;cocol is not warped by analytical constraints. 
Whenever statistical pro::edures (such as classical hypothesis testing) 
are applied to data, certain mathematical assumptions (of scale and 
distribution) about that data must be met. In too many educational 
settings, the Importance of these assumptions is ignored. Yet 
arbitrary assumptions lead to technically invalid or misleading 
analyses. We will discuss some common statistical pitfalls in more 
detail after we demonstrate how we have analyzed errors recorded in 
students' protocols. 
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An example taken from Simper protocol data Illustrates the nature 

of our analysis. The example shows how one student suddenly seemed to 

grasp a concept with which he had been having trouble — name-value 

association (addressing) in Simper. If the programming is unclear, the 

reader should refer back to Section 2.1, keeping in mind that a modified 

Simper is described there. The student's dialog with Simper is 

reproduced here as he was engaged in writing a program to realize the 
2 

function: x - 3 : 

003 :2 

015 :ASK A 

016 : STORE A 200 

017 :MULTIPLY A A 

018 : SUBTRACT A 3 

019 :WRITE A 

020 :RUN 15/ 

He appears to understand the purpose of addressing in 'STORE A 200', but 
his program contains several errozs that suggest otherwise. The first 
causes execution to stop at 017 because the S3nDbol "A", used in the 
address field of the instruction in 017, has no binding and thus no 
associated value. The student thought he could square the A register's 
content with the instruction: 'MULTIPLY A A', and he thought he could 
subtract 3 trom that with: 'SUBTRACT A 3'o In both cases, the meaning 
ot the register field seems to be understood, but the address field is 
misunderstood. The student corrects the first error (messages from the 
interpreter are in lower-case) : 

020 :FIX 17 

017 :MULTIPLY 200 200 

200 isn't a register, use a, b, or p 

017 :MULTIPLY A 200 

020 :RUN . 
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and the program works except that, because location 3 contains the value 
2, the subtraction doesn't do what he expected. At this point he seems 
to understand that he can store and access values via addresses (names) 
because of his correct use of the register and address fields of the 
'STORE' and 'SUBTRACT' Instructions. But the Idea crystallizes: 

020 :FIX 201 
201 :3 

when he associates the desired value 3 with the name (location) 201, 

020 :FIX 18 

018 : SUBTRACT A 201 

and correctly accesses It to complete his program. From this dialog, one 
can see the student begin to apply the concept In correct fashion (In the 
'STORE' Instruction), then fall because he has not yet mastered it fully, 
and finally succeed, partly helped by simple error diagnostics. The 
student later made a similar mistake, but corrected it at once. 

For the purposes of the experiment, this type of analysis can 
suggest when and how a student masters something presented in the 
curricula. Students can be compared in far greater detail than can be 
achieved with discrete tests, the curricula and languages may be 
evaluated very finely, and the preliminary aptitude test's validity may 
be rated subjectively. 

Protocol analysis also allows us to evaluate the languages by 
showing us how they help or confuse novice programmers. The following 
are brief examples from Logo and Simper protocols of absurd or 
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misleading responses to syntactic errors • First, consider: 



_PRINT :::SNOOPY::: 

don^t use the empty thing for a name 

in which the student *s obvious attempt at multiple indirect-addressing 
is completely misconstrued by Logons simplistic parsing (the first pair 
of colons are found to contain no name string). And second: 

001 : SUBTRACT 1 FROM P 

002 :RUN 

warning! you forgot to name a location fromp 
illegal memory reference 0 at 1 

in which Simper, striving to extract three fields and no more from the 
student's line, compressed a simple syntactic error and generated a more 
advanced type of error. Not only was this spurious error unrelated to 
what the student had done, it exposed the student to a situation for 
which he was not yet prepared (i.e. the use of assembler symbols). 

Examples like those can be used to guide language design. Since 
the experiment discussed in this report was in part a pilot study for a 
later experiment, our protocol studies led to changes in Logo and Simper 
in preparation for that experiment. 

It should be clear that the interpreters we have used are not 
"smart". They do not tutor their users on the semantics of programs — 
in the experiment, that was left to humans. The interpreters do little 
more than trap syntactic errors, sometimes acceptably wall: 
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001 : SHIFT 

unspecified register, use a-, b, or p 
001 : SHIFT 76 

76 isn^t a register, use a, b, or p 
001 : SHIFT A 

shift uses 1, or r or @ and a number in the address field 
001 : SHIFT @56 

(§56 isn*t a register, use a, b, or p 
001 : SHIFT L 56 

1 isn*t a register, use a, b, or p 
001 :SHIFT A L57 



As we mentioned earlier, a simple analysis of the protocol files 
was also carried out (e.g. Figure 16) to provide us with a few summary 
statistics which might point to difficult areas of the curricula or 
give us a very coarse measure of student performance. For example, if 
a Simper student *s errors were categorized and plotted as in the graph 
in Figure 16, an interesting effect usually could be observed: 
familiarization with the language led to a decrease in errors classed as 
syntactic and an increase in those classed as semantic. We infer that 
as students increase their active programming vocabulary, they can 
more easily realize their ideas about problems as programs and find that 
their ideas (now programs) aren*t always debugged. This is more 
reasonably corroborated by tutorial data and detailed protocol analysis. 



We now return to our general discussion of the care which must be, 
yet often is not, exercised in applying classical statistical techniques 
to the analysis of data like those generated by our experiment. 



"It is a capital mistake to theorize before one has data. 
Insensibly one begins to twist facts to suit theories, 
instead of theories to suit facts." (Sherlock Holmes, by 
Sir Arthur Conan Doyle) 
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blU163.dta;3 AUGUST 1, 1973 12:20PM 



1 DAYS, 1 LOGINS, 33.40 MINUTES ON, 372 KEYS TYPED ON 60 LINES. 
RESPONSE DEUY, MEAN & DEVIATION: 32.15 34.36 SEC. 

I. 00 LOGINS/DAY, 33.40 MINUTES/DAY, 372.00 KEYS/DAY 
33.40 MINUTES/LOGIN, 372.00 KEYS/LOGIN, 60.00 LINES/LOGIN 

II. 14 KEYS/MINUTE, 6.20 KEYS/LINE, 1.80 LINES /MINUTE 
36 ERRORS: 36 GENERAL, 0 NAME, 0 RUN, 0 FIXUPS 

36 SYNTAX ERRORS, .60 SYNTAX ERRORS/LINE, 1.08 SYNTAX ERRORS/MINUTE 
.00 RUN ERRORS /LINE, .00 RUN ERRORS /MINUTE 

0 10 20 30 40 50 60 

. I . I . I . I . I . I 

1 #////////////////////////#////«# 

2 //////////«#// 

3 M 

4 // 

5 // 

6 // 

7 // 

8 // 

1 UNSPECIFIED REGISTER, USE A, B, OR P 

2 EMPTY ADDRESS FIELD? 

3 SHIFT & ROTATE USE L, R OR @ & A NUMBER IN THE ADDRESS FIELD 

4 EXCHANGE USES A REGISTER IN THE ADDRESS FIELD 

5 ONLY VALUES FROM 0 TO 999 MAY BE PUT 

6 " ISN'T A REGISTER, USE A, B, OR P 

7 SHIFTS OR ROTATES MUST BE BETWEEN -999 & +999 

8 UNKNOWN OPERATION 



0.2 + 



Errors per 
Command Line 0.1 + 



0 +■ 
0 




semantic 



— 2*; 

12 3 4 
Weeks in Course 



Fig 16, A Simple Quantitative Analysis of Protocols. 
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Conan Doyle and his Holmes were not statisticians, but the quoted 
remark is nevertheless apt* In the social sciences, especially in 
education, the style of research too often reflects a Quixotic quest for 
numerical results, apparently stemming from the belief that 
quantitativeness is a precursor of objectivity and respectability in 
one*s discipline. 

"They use statistics as a drunkard uses lampposts, 
for support rat;her than illumination." (Andrew Lang) 

(the reader is welcome to replace "statistics" with "references" or 
"quotations") . This is amplified by the relatively easy access most 
researchers now have to computerized statistical procedures (Ellis, 
1972). Perhaps more seriously, widespread use of standardized 
procedures has led to stereotyped theorizing (e.g» to hypothesis testing 
restricted to linear models and Noiinal distribution theory — procedure 
defines theory) , while the implicit assumptions of the procedures are 
virtually ignored, 

Consider, ^'or example, cur preliminary test (Section 3) for 
"programming aptitude", whatever that may be. We could score the 
results of students* work on it on some scale, say 0 to 100, to get a 
list of numbers that could, perhaps along with other numerical data, be 
injected into a vast number of standard statistical programs. We could 
compute correlation and regression coefficients, and test hypotheses. 
But, the relevant statistical procedures have been derived from a set of 
first principles and assumptions. What about them? Mustn't all the 
restrictions they Imply be met reasonably well by our data and the 
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scoring process'' Are the theories defined by these procedures relevant 
to the kinds of questions we wish to ask about, and will they shed light 
upon, the real-life process that produced the data? 

Take for Instance the word "scale", used In describing how we might 
produce "scores" for our students. Many (educational) researchers 
believe that tests define scales. But a scale of measurement Is a 
well-defined mathematical object. It Is an abstraction of a particular 
property of other objects. Every device (test) that purports to 
generate a scale must, apart from truly measuring some property, produce 
results which do not violate the principles which define a scale. For 
Instance, to be represented on an Interval scale (as points on the 
number line), data must have (among others) the property of transitivity 
of point and Interval. In other words, any data points a, b and c 
obeying, for Instance, the relation: a > b > c must also obey: a > c; 
similarly, any Intervals p-q, r-s and t-u obeying: p-q > r-s > t-u must 
also obey: p^-q > t-u; and so on, for other relations. Valid test 
scores cannot be taken as Interval-scale data unless all scores which 
differ by equar imerlcal amounts Imply equal differences In amount of 
the property measured by the test. So, a test must be uniformly valid. 
Consider the much-maligned "IQ" (standardized intelligence) test. 
Students who score between 50 and 60 must differ respectively and by 
exactly as much In whatever the test measures is do those who score 
between 120 and 130, and so on, for all possible differential scores, 
otherwise the score data are at most of ordinal significance. 
Unfortunately, svch data are often reported as Interval data. This can 
be, for at least three reasons, misleading or plainly wrong. 
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First, students who score low on a test do so because they know how 
to answer few questions, while students who score high may answer the 
low-scorers* questions and others as well^ Different questions 
(answered by different students) alledgedly test different abilities, 
intentionally so. Tests are often divided into subtests which reflect 
*.he theoretically diverse abilities to be tested. But combining scores 
from all questions on a test into one descriptor may negate the 
assumption that equal score intervals are commensurate. Unless all 
questions or subtests can be shown to be disjoint and distinct in the 
same way for every student who takes the test, reporting one summary 
statistic per student and presenting a distribution is folly. An inch 
at the low end of a yardstick measures as well and means the same thing 
as an inch at the high end. Can the same be said for IQ or many other 
mental tests? Saying that such tests "measure what they measure" 
skirts fundamental mathematical issues of data representation. They 
are not analogues of yardsticks. 

Second, a measuring instrument which interacts with the individuals 
it measures may net produce even ordinal data. Consider the cultural 
bias which various tests are said to impose upon the testee — an 
allegation that has recently been sustained in some courts. Tests 
which ask humans to think will observe human thinking, subject to the 
^^agaries of human psychology. How useful is a yardstick that is highly 
and ambiguously sensitive to heat, light and the day of the week? 

Third and last, even if a test validly represents its results as 
interval data, those data are often "standardized" by transformation 
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into a convenient discributional form, often the Gaussian (Normal), 
which may have nothing whatever to do with the population process that 
gave rise to the data. Such preprocessing ("transgeneration") is 
common co many computerized statistical procedures, and can be 
legitimate. But, for instance, IQ data is manipulated by hook or crook 
to fit a Gaussian form. Obviously, at most ordinality is preserved, 
and the resulting "bell-curve" is totally without redeeming scientific 
importance. Forcibly molding data to fit analytical constraints can 
destroy the meaning of both the data and the analysis. Of what use is 
a "silly-putty" yardstick, perhaps grading from meters to fathoms to 
feet, if the questions we ask of its measurements cannot properly 
account for its latest non-linear form? 

Apparently, we do not understand the psychology of testing (or 
learning) well enough to fairly represent mental-test results as more 
than ordinal data. But analyses derived from distribution theory, like 
regression, correlation, and analysis of variance and covar lance, assume 
that the data they operate upon is at least interval-scale data. And 
such procedures are applied daily to mental-test scores. What can be 
inferred from such misapplications? Mathematically and scientifically, 
nothing. Blind use cf statistical procedures can only give a false 
sense of objectivity. One does not: have a scientific result when one 
applies an analytical technique in violation of any assumptions on which 
that technique was derived, unless one also has a theory which describes 
the perturbations induced by each and every violation ("robustness" and 
the "law of large numbers" don*t so qualify). One seems to have 
results, because procedures can*t judge the source and calibre of their 
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numerical input — cube roots of license-plate numerals observed in 
travelling cross-country will feed most procedures, but what do they 
measure? Any act of measurement, physical or social, must be done in 
the light of a theory of how the measurement interacts with the 
measured. Not a trivial theory (e.g-, of signal-plus-Gaussian-noise as 
in classical test theory), but a theory that defines the signal (and 
scale axioms) in relation to other objects. Yardsticks and radar can 
abstract the same property of objects, but it is the same property 
because the theories of the two devices mesh. Statistics enters only 
as a '^theory of errors", when we wish to judge "noisy" measurements in 
some organized way; the noise is ancillary to, yet affects not the 
theory of, the signal. But variations in human behavior (e.g. as 
"measured" in educational testing) are not always noise to be described 
away by statistical conveniences like analysis of variance. Likely as 
not they are data whose meaning might point to reasonable educational 
theories that ha\e eluded simplistic analyses, or, sampling from Renee 
Haynes' postscript for Koestler (19^3): 

"This matter of quality as contrasted with measurement . ^ . 
seems to me to emerge with ever-increasing urgency. It 
cannct be ignored simply because it is so uncomfortable aad 
so difficult to deal with. It is relevant to science 
Yet (because it is so much easier to accumulate and to 
quantify data than to reflect on their significance) 
quality and meaning, which matter most to men, tend to be 
brushed aside " 

Research that applies "damn-the-tcrpedoes" quantitativeness produces no 
results, because the link between the data and the analysis has been 
broken, for instance, by vacuous scaling. Yet there might have been 
results. Many valid analyses can be carried out on a body of data 
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without the need for cavalier assumptions about Its structure (e*g« see 
Bradley, 1968 or Purl, 1970) • The analysis should fit the data, not 
the other way around, to paraphrase Sherlock Holmes • 

Misuse of scales is only one criticism that can be levied against 
free-wheeling statistics. Here, we will not discuss others, which 
range frcm data-"improvement" techniques like 'Vindsorizing" to 
confusions of deduction and induction. Let us return to the example of 
our own test. 

The preliminaiy aptitude test's results were presented as a rank- 
ordering of our students (Figure 15) obtained by a "forced-choice" 
evaluation of their work, Perhaps even this is not justifiable, for a 
test whose validity has yet to be determined by experimental results. 
At least a few students, especially near the median, might well be 
reordered or considered hopelessly tied. Yet rank-ordering enforces 
transitivity. The theory behind cur test is simple and qualitative: 
take as questions examples ot the thinking that programmers are 
typically asked to do, where some cjrpes of thinking are more important, 
in the progranmiing sense, than others. The former relates to validity, 
the latter to t ransiti^^lty. No part of the theory suggests cardlnation 
or Interval scaling. We feel that a carefu?., subjective evaluation of 
constructive answers produced by students can more nearly approximate an 
objective technique (if one exists) for ranking them than can a falsely 
objective ces ting/scoring procedure. Our thecry may be wrong or 
incomplete^ but determining that is one purpose of the experiment: what 
do students' interactions with the zest have to do with theif 
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interactions with the course and with prograiraning? Again, theory is 
eternally subject to data* The test's initial validity teeters on our 
subjective choice of questions, and it will stand or fall depending upon 
experimental results. Surprisingly many mental tests go unevaluated by 
their users who nonetheless report results of their use (e.g. see Folk 
et al. 1973 — although we have been critical of their application of 
statistics, their report is otherwise valuable). 

Why is misuse of statistical procedures common, perhaps growing? 
Apparently because many believe that social/psychological research can 
only be substantive if it mimics the quantitativeness of the physical 
sciences. Ultimately, dispelling this rationale is the responsibility 
of statistics teachers (especially those who teach, or are, 
nonstatisticians), who must instill not only broader knowledge, but a 
sense of responsibility and respect for the use of statistical inference 
in decision making and theory building. 

6^ Results 

Virtually every component of the experiment was evaluated in some 
way. The students provided feedback both directly and indirectly, by 
supplying specific opinions to us and by our observations of their 
behavior and attitudes. Figure 17 summarizes the students' responses 
to a questionaire they received from us shortly after the experiment 
had terminated. The total numbers of opinions for all rows are not 



* We are indebted to Mario Zanotti for sharing with us his knowledge of 
the foundations of mathematics and statistical inference* 
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Tone of Student Remarks 



Subject 


Negative 


Noncommittal 


Positive 


Plotter 




1 


16 


Graphics Turtle 




2 


26 


Games 




3 


25 


Tutors 


2 


3 


25 


Return again 


2 


3 


25 


Train 




3 


14 


Robot Turtle 


1 


1 


9 


Logo 




8 


21 


Logo Lessons 


3 


8 


18 


Simper Lessons 




5 


5 


Simper 


3 


3 


5 


(R) 

Teletypes^ ^ 


4 


12 


11 



Subjects are ranked on relative fraction of positive remarks. 

Fig. 17. Student Preferences. 

Identical because some students responded partially and others were not 
sufficiently exposed to every item to render an opinion. 

Most of the preferences expressed in Figure 17 correlate with 

casual comments made by the students during the experiment. For 

instance, the plotter was preferred to the robot because "it draws 

better" (it produces more faithful drawings) . The plotter was 

(R) 

preferred to the IMLAG graphics because it produces portable, 
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permanent results, and because one can "see it work" — this fascination 
might have worn off had we had the plotter longer. Graphics was 
preferred to the robot because it was faster, more accurate, and 
personally available for each student. Animation could not influence 
these opinions because it was not available until the very end of the 
experiment • 

The item listed as "games" in Figure 17 refers to certain programs 
accessible to students on the IMSSS system, such as Hangman, which were 
intentionally not announced until the students completed most of the 
curricula. Some students, of course, accidentally discovered a game or 
two. Our policy was that games could be used after a student's daily 
session with Logo or Simper. The most popular games were: highly 
interactive, like Hangman; those involving more than one player, like 
Poker; and those with plenty of action, like Spacewar. Wordy, random- 
number-driven games, like Football, were thought "dumb"; unless they 
tickled a specific interest, as Startrek often seems to dOw Games were 
ranked to give us an idea of their place in the students' view of the 
experiment. V/e encouraged students to write their own games and used 
some as examples in the curricula. 

One prevalent opinion among students familiar with both Logo and 
Simper was that "it's harder to do things in Simper". This resulted in 
most students preferiing to work with Logo, regardless ot the starting 
language. Figure 18 tabulates the proportion of time students spent 
using Logo (and, by complementation, spent using Simper) for all non- 
graphics students ^ Note that, within each group, students are ordered 
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(Logo hours / Simper + Logo hours, versus pretest rank, 
"-" denotes students who took the test but not the course) 



Group 

.99 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxmxxxxxxxx 

1.0 xxxxxxxxxxxxmxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1.0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1.0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1.0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.98 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1.0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1.0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1.0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

1.0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.99 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxmxxxxxxxxxxx 



Group II 

.70 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.34 XXXXXXXXXXXXXXXXX 

.48 xxxxxxxxxxxxxxxxxxxxxxxx 

.22 XXXXXXXXXXX 

.31 XXXXXXXXXXXXXXXx 
0.0 

.17 XXXXXXXXx 

0.0 

.04 XX 
0.0 



Group III 

.82 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.69 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.64 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.87 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.67 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.69 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.68 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.68 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

.88 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 



Fig. 18. Breakdown of Students' Programming Time. 
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by pretest rank* Thus Figure 18 may be correlated with Figure 15 to 
obtain further Information. This convention will be observed In other 
figures In this section, whenever it is appropriate. 

Because few students finished (reached the last part of) the Logo 
curriculum, Group I spent negligible time with Simper. But many Group 
II students went far enough with Simper to be able to start Logo, partly 
motivated by their seeing their friends' work. What is interesting 
about Group II 's behavior is that the students who began using Logo 
stayed with it, virtually co the exclusion of further work with Simper. 
Figure 18 also shows that students given simultaneous access to Simper 
and Logo (Group III), and subject only to the stricture that Simper and 
Logo curricula parts alternated, chose to spend most of their time with 
Logo. This group answered a capability question: students can learn 
both languages, nearly simultaneously, and do so faster than students 
who learn the same languages sequentially* 

Mass preterence of Logo to Simper was, in our view, a desirable 
outcome in terms of the students' computer literacy « Although Simper 
provides a convenient way cj learn and experiment with assembly /machine 
language programming, students could see the advantage of a high-level 
language. Logo offers what students seem to want: easy access to 
message and picture processing* It offers a computationally more 
important feature: ease of phrasing complicated control structures. 
However, we found that appreciation of this latter idea was usually 
confined to the more able students. 
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Before further discussing the students' behavior, let us consider 
gross aspects of what the experiment suggested concerning the validity 
of the preliminary test* For Group II, Figure 18 indicates a 
correlation between students* ranks on the pretest and the time they 
needed to complete the bulk of the Simper curriculum* Because of the 
general desire to use Logo and our inability to distinguish (from 
summary protocol analysis) personally-motivated use from curriculum- 
motivated use, the data for the other groups do not relate to pretest 
rank. Students were also ranked by us and the tutors according to 
programming ability and dedication to the tasks presented to them in the 
curricula. Figure 19 shows these ratings, again by pretest rank, for 
all Simper students. 

Figure 19 also tabulates the mean rate of errors in each student's 
commands throughout his or her work with Simper. Some slight, joint 
trend of error rate and pretest rank seems evident. For example, the 
median rate (.11) for those above median rank is much lower than the 
median rate (.26) for those below median rank. The reader can easily 
find other indicators of asymmetry in this sample of data that suggest a 
positive correlation between rank and error rate. However, we must 
caution that averaging errors in this way blurs the nature and 
importance of individual errors. Without referring to detailed 
protocol analysis, such a correlation merits little more than a "that's 
nice". We should mention that typing and reading ability varied 
greatly among the students. Furthermore, some students forged along, 
not caring how many errors they made, while others worried Inordinately 
about making mistakes, particularly observed ones. Various 
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Groups II and III (Simper data) 

denotes students who worked less than 3 hours) 

Rankings Based Upon Subjective 
Evaluation of Performanc e 
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Fig. 19^ Simper Students' Performance Versus Pretest Rank. 



combinations of such abilities and attitudes obviously can confuse 
simple comparisons of error laces* It happens that the fourth-ranked 
student (Figure 19, with a high error-rate) fell Into the "unbridled 
tjrplst" category; the third and fourth from the bottom (with low error- 
rates) were extremely careful, tending to work out commands on paper 
before typing them; and the fifth from the bottom had a penchant for 
typing random numerals, which never appeared as errors because Simper 
was perfectly happy to store them away. Apparently anomalous error- 
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rates can have explanations that can improve the apparent correlation of 
pretest rank and error rate. 

Examining the "mastery" and "perseverance" columns of Figure 19, we 
also see some mutual trends with pretest rank. High rankers, 
especially in mastery, tend to be above the median; low rankers below* 
Figure 20 shows similar results for Logo students. Note, however, the 
lack of obvious mutual trend between error rate and rank in Figure 20. 

Protocols provide the following explanations. In Groups I and 
III: the unbridled typist returns with a friend as the fourth- and 
fifth-ranked students; careful planners are bottom and third from the 
bottom; the random-numeral typer is now caught by Logo, generating a 
higher rate, sixth from the bottom; and a new phenomenon: picture- 
printers, fifth, tenth and eleventh from the bottom, who discovered how 
'PRINT' commands could be employed in procedures that "drew" their 
favorite things (like the "Starship Enterprise") . The latter three 
students made relatively fewer errors because they stagnated at this 
point in the curriculum. We did not intend to coerce any student to 
continued the curriculum, rather, we adopted a wait-and-see attitude, 
hoping they would eventually notice that other things, being done by 
other students, could also be interesting. This tack failed with one 
of these three students. 

In Groups IV and V: paired students tended to make fewer errors 
because commands often were agreed upon by both partners before being 
typing, but pairs typically consisted of students low in the pretest 
ranking. One paired student, fifth from the bottom, had a partner who 
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("-" denotes students who worked less than 3 hours) 

Rankings Based Upon Subjective 
Evaluation of Performance 

Errors per Command Mastery Perseverance 

Groups and III (Logo data) 
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Fig. 20. Logo Students' Perfomance Versus Pretest Rank. 
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dropped out early In the experiment. She was extremely secretive about 
her work, which focussed upon drawing many different styles of castles 
via direct Logo commands — an analogue of the 'PRINT' hang-up above. 

In general, students experimented more with Logo than they did with 
Simper, apparently because they felt more able to express their Ideas In 
Logo. This partially explains why the median error-rate for 
nongraphlcs, Logo students (.24) Is higher than that for Simper students 



If we consider our ratings of students, students' error-rates, and 
time needed to complete a curriculum as valid Indicators of programming 
competence, then we can say that the preliminary test seems tc be a 
usefully valid means for ranking programming neophytes. 

6. 1 Understanding the Students 

This section relates most directly to our central interest: how do 
students learn programming and what can observations of that learaing 
process tell us about student/ tutor interactions in general. Our 
discussions stem primarily from protocol analysis. We consider first 
Simper then Logo. 

Simper. We begin with the initial, un tempered ideas about 
computers that our students brought to the course: 



(.16). 



HELLO WHAT'S NEW? 



DO YOU WANT TO PLAY JOTTO? 



DO YOU LIKE SUMMER? 



I AM FUNNY 



THIS TYPEWRITER IS TOO SLOW 



SOME DOGS ARE IffllTE 
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WHAT IS 12X12? 



HOW DO YOU WORK? 



TEACH ME HOW TO DO A PROGRAM HOW DO YOU KNOW? 

THERE ARE TWO MILLION FLYS IN AMERICA 

DEAR JUDY, THIS COMPUTER CLASS IS A LOT OF FUN. 
EVERY ONCE IN A WHILE THE COMPUTER GOES WACKEY! 

Of course, we had encouraged the students to plumb Simper "miad", and 
all the above efforts received no more than "unknown operation xxx" in 
reply. But a few students fortuitously struck upon operations as in: 



where 'COM* is short for the 'COMPARE* operation. This piqued their 
curiosity; some explored this new level of interaction ad-nauseam, but 
they remembered Simper's abbreviation-by-truncation for later 
exploitation. 

Our naive programmers often had a very high opinion of 
computational technology. It was easy to show them that English is not 
yet a mode of communication between human and machine, but it took some 
time for the implications of this to penetrate. 

At times, students' attempts at communication were tied to 
curriculum ideas: 



001 : COMPUTERS ARE FUNNY 

*are' isn't a register, use a, b, or p 

001 : COMMAND YOU 

'you* isn't a register, use a, b, or p 



REMARK LITERALLY 



PUT A BUG IN A 



SIMPER COMMANDS ARE FAMILIAR TO COMPUTERS LIKE SIMPER 



WILL YOU WRITE ME SOME SIMPER PLEASE 
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001 :3 4 10 ARE RELATIVE TO THE NUMBERS 15, 17, 29* 

IN WHAT WAY THOUGH? 
unknown operation 3 

001 :3 (THREE) IS A NUMBER AND ALL COMPUTERS LIKE YOU 
SHOULD KNOW WHAT IT I^IEANS! 



Sometimes they became confused about the curriculum instructions 
for typing commands. The following shows some examples along with the 
motivating curriculum excerpt: 

LINEFEED ... all you do is type LINEFEED and . • • 

1 TYPING 1 ... and then typing 1 and ENTER . . . 

GO TO THE SUPERMARKET (see Appendix 5, curriculum page 17S) 
BUY EGGS AND BACON 

FIX PUT P 2 TO P 1 RUN ... use FIX to change . . . from PUT P 2 

to PUT P 1 and then use RUN and ... 

In fact, some students t/ped Simper ^s prompt because it had been shown 
at the beginning of a line they were asked to type: 



001 :001: ADD A 12 
unknown operation 001: 



One student tried tc get a program to run by simulating Simper *s runtime 
message: 

007 :EXECUTING 1 TO 250 
unknown operation executing 

producing an enjoyably idiotic response. Another student, in his 
frustration, uncovered a bug; not in Simper, but in the Sail compiler's 
string run-time-routines: 



005 :,YOU STUPID COMPUTER 

•stupid* isn't a register use a, b, or p 
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The bug disguised the and thus the proper error: "unknown operation 
,you". 

Other confusions arose when students worked with both Logo and 
Simper (as did Group III) . Logo commands cropped up in Simper 
protocols and vice-versa. In these cases, however, the first or second 
error message usually was sufficient to remind the student of which 
interpreter was listening to his or her typing. In a few cases, 
students thought they could resort to Logo commands when their Simper 
programs failed to produce results. By far the most common 
interjection of Logo was in saving programs. Apparently, learning the 
more complicated Logo scheme of "entries" in "files" overrode some 
students' knowledge of Simper's simpler filing method. 

At the very least, most students initially thought that a computer 
could help them on a personal basis. We agree; that should, and 
perhaps will, someday be the case. Several discovered the '?' (or 
'HELP') command which printed a general description of the Simper 
language. While this was never intended to be a necessary part of the 
course, it nonetheless was exercised frequently by a few students. 
Curiousity and an open desire for aid were attitudes we had hoped to 
exploit and certainly not to diminish. Students' were willing to 
experiment in t.ryjLafif to use Simper as an information resource to help 
them work out ideas from the curriculum. Unfortunately, some of their 
attempts were stymied by our sometimes misleading verbiage or notation. 
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since work with numbers was so much a part of our students' prior 
schooling, It was relatively easy for them to accept that a machine 
(Simper) could have a good memory for numerals. But understanding that 
some numerals had a special meaning, other than for counting, to a 
machine was a more difficult concept. This was partly a problem 
because of the premature Introduction of assembly language, thus working 
downward from English rather than upward from machine language. 
Perhaps the correct sequence would also have reduced the incidence of 
syntactic errors such as multiple Instructions per line, making it clear 
that only three fields can be assembled into one location's machine- 
language numeral. As a result of this, we added a program which wrote 
over Itself by reading numerals from the student. The only way this 
program could keep running would be If the student typed (as Instructed) 
the numerals which were the program's very Instructions. This usually 
clarified matters. 

The orderly execution cf numerals as instructions was still more 
abstract. The shopping list example (Appendix 5, curriculum page 17S) 
and the house-to-house collection (Appendix 5, curriculum page 22S) 
failed to motivate successor execution for some students. Programs 
were written with interspersed "holes", despite the obviously sequential 
relationship between instructions on either side of a hole. The self- 
destrucclng program mentioned above helped here as well. 

Addressing remained a difficult idea for many students. One 
student wrote his own time-telling program, knew what had to be done 
to get minutes from seconds, knew something about addressing already, 
but typed: 
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001 :TIME A 

002 : DIVIDE A 60 



though he did not intend to divide by the content of location 60* The 
section on indirect addressing was very helpful to those students who 
still had trouble with this concept. Students who had trouble with the 
implicit name/value associations of the i;uinbers-in-boxes problem on the 
preliminary test also had trouble with addressing in Simper. 

The most pervasive problem was mastering the concept of context (or 
locality of information) both from the student's point of view as a user 
and from the point of view of instructions within his or her programs. 
The most common example of the former typically occurred when a student 
ran a program and decided that it needed modification. While it was 
still running, and perhapa waiting for an input (for 'CASK' or 'ASK'), 
he or she would type an editing command (e.g. 'LIST' or 'SCRATCH'), 
fully expecting it to be obeyed. Examples of the latter centered upon 
redundant or "clobbering" sets of instructions. For instance: 



001 :PUT B 1 001 

002 : STORE B ONE 002 

003 :ASK A or 003 

004 :PUT B 1 004 

005 : STORE B ONE 005 



PUT B 1 
STORE B ONE 
ASK B 
STORE B @A 
PUT P .-3 
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In the first program, the context within the machine Is unnecessarily 
reset at 004 and 00 1-; in the second, the content of location 'ONE' is 
continually destroyed by 'PUT P .-3'. This latter form is a common 
kind of bug and had already been exploited as such within the 
curriculum. It was apparent, however, that a much more explicit 
treatment of computational context was needed. Students who had the 
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most trouble with the candy-machine problem on the pretest also had 
the most trouble organising chelr Simper programs. 

The most subtle way In which context affected the students was In 
the relationship among the Interpreter, the assembler and the machine* 
Students did not fully grasp the distinction between editing commands 
and assembler/machine instructions. Sometimes they attempted to 
abbreviate the former (e.g. "sCR" for * SCRATCH 0 and expect the latter 
to be obeyed at once. Again we modified the curriculum in an attempt 
to clarify these Issues, some of which were founded upon confusing 
editing time with execution time. 

Some of the "holey" programming can be traced to Group III students 
who learned to use Logo line-numbers in canonlcally sparse (10-20-30...) 
sequence and hoped the same editing adv'antages would accrue in Simper. 

Toward the end of the curriculum, procedures and their calling 
sequences provided examples of how programs could be structured by 
writing functionally related subunlts. In this case, holes were ok. 
Success here demanded that the student had mastered the concepts of 
addressing and program control. Failures to structure these programs 
correctly were of two forms: failure to define a proper calling 
sequence, and misplacement of the calling sequence in the flow of the 
program. Some Inputs to procedures, particularly the return address, 
were overlooked; once the call Itself was Incorporated as part of the 
procedure body. 
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Because no students had time to do significant work on the final 
part of the curriculum dealing with stacks and recursive procedures, we 
lack some potentially interesting data. The notion of context could 
perhaps be motivated very well here. However, our sequential pass 
through the curriculum has failed to mention that we have been relying 
increasingly upon data from the more able, typically older, students. 
The remaining students simply did not proceed as far. How this has 
colored our observations we can't say, but we can say that students who 
had trouble seeing any valuable return for their relatively large 
programming efforts (in com^parison with Logo) tended not to proceed with 
the curriculum and felt that they would "never understand Simper". And 
these students were usually, but not always, less than the most able. 

A few miscellaneous comments remain. Some students were active in 
exploiting features of the Simper interpreter 2or instance, the 
truncation of operation names (e*g. 'STOP* for 'STORE* and 'LOAN' for 
'LOAD'). One student occasionally seemed to harass the machine by 
repeatedly saving a program on a file that already existed just so he 
could respond "no" to Simper's warning: "a program called xxx already 
exists! ok to destroy it?". The importance of clear, relevant error 
messages also became apparent (see Section 5 for examples). An 
example of how misreading one word can dangerously alter the meaning of 
a message: 

010 :SAVE 

what do you want to name your program? YES 
ok, yes is saved 

illustrates the care that must be applied to apparently trivial aspects 
of an interpreter. In line with our earlier comments about contextual 
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errors, we should mention that the above question and the students 
together produced a large number of saved programs called 'SCRATCH', 



Logo , After showing students how to log In to the system, the 
curriculum encouraged them to tjrpe any line they wished to the Logo 
Interpreter. This was for the purpose of demonstrating Logo's 
understanding of English as well as giving us some understanding of what 
the students expected the computer to be: numerical calculator, 
omniscient authority, or game player: 



COMPUTERS ARE DUMB 
computers needs a meaning 
COMPUTERS ARE ILLOGICAL 



THIS IS GOING TO BE VERY FUN 

this needs a meaning. 

IT MEANS IT WILL BE ENJOYABLE 



HOW MANY QUESTIONS CAN YOU ANSWER? 



HOW LONG HAVE YOU BEEN IN SERVICE? 
how needs a meaning 
YES 

yes needs a meaning. 
AFFIRMATIVE 

affirmative needs a meaning. 
YES MEANS AGREED, CORRECT 
yes needs a meaning. 
I JUST GAVE YOU A MEANING 
1 needs a meaning* 
I MEANS //176 
1 needs a meaning. 
I GIVE UP 



HOW MANY WORDS DO YOU KNOW? 

WHY ARE YOU A COMPUTER? 

WHERE IS GERMANY? 

you are not using the train 

YES I AM 



MY DOG IS BLACK 
THE SUNSET IS BEAUTIFUL 
PLAY CHESS 

play needs a meaning. 
PLAY MEANS TO DO SOMETHING 

GET GOLF 

something missing for get. 
GET GAME 
something missing for get. 
GET PLAY 

something missing for get. 
YOU ARE A STUPID COMPUTER 



After learning about literals and several commands. Groups I and 
III began Part 4, while the graphics groups spent several days drawing 
pictures with the direct commands learned in Part 3 — two examples were 
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a drum set and a cube with legs* While we did not want to stifle 
Individual expression and force students to go through the curriculum at 
the same rate, we also did not want them to grow addicted to Immediate 
results and frustrated by the lack of more powerful tools (l.e» 
procedures) through which they could edit, store and reproduce their 
pictures. These factors may be responsible for several of our early 
dropouts. Had procedures been Introduced at the beginning, a student 
would have had a framework within which to execute direct commands and 
then add them to his/her procedure via simple editing commands. 

Students In Part 4 sometimes forgot to quote literals, either as 
names or values, 'MAKE "ALPHABET" ABCDEFGHIJKLMNOPQRSTUVXWYZ ' ; they 
reversed name and value positions, 'MAKE SUM OF 5 AND 9 ANSWER'; or 
they attempted linked assignment through one command (not an 
unreasonable expectation), e.g. 'MAKE "SNOOPY" "CHARLIE BROWN" "LINUS"* 
(where the curriculum intended 'MAKE "SNOOPY" "CHARLIE BROWN"' and 'MAKE 
"CHARLIE BROM" "LINUS"'). 

Some initial confusion about Logo's colon notation (i.e. 'THING OF 
"SNOOPY"' could be written alternatively as 'rSNOOPY:') resulted from 
the poor quality of our photocopied lineprinter listings: some students 
mistook ";" or for ":". Others tried expressions such as 
^: SNOOPY::' to mean 'THING OF THING OF "SNOOPY"', but Logo 
(inconsistently) does not permit the nesting of colons. Logo allows 
numbers to be names also but this later led to some unfortunate 
confusions between litexals and names, and actual and formal parameters. 
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Armed with the procedure examples from Part 5 and the ^PRINT* 
command, many students chose to make posters and print endless 
statements • 



TO TOM 

10 PRINT 'If TOM WAS NOT GREAT I WOULD STOP WRITING" 

20 TOM 

END 



Pictures of various Star Trek ships appeared ( 'KLINGON. BATTLE. CRUISER ^ , 
^ENTERPRISE', and 'GALILEO') as well as interpretations of the human 
anatomy. Students wrote procedures for each letter of the alphabet and 
other procedures to type messages one letter at a time. For example: 



TO HELLO Still the concept of a literal string was not firm in 



since all but one blank between words is deleted when sentences are 
stored). Studencs may have believed that // was a command to type 
blanks and therefore (correctly) did not quote it. After Part 6 (and 
with the aid of the tirsc page of Part 9), the students could specify 
messages as Logo strings, e.g. 'POSTER "HELLO"', 'POSTER "TELETYPES HAVE 
PORNOGRAPHIC MEMORY BANKS"' and 'POSTER "THIS SIGN HAS NO MEANING IT HAS 
NO INPUT AND GIVES NO OUTPUT"'* Despite high enthusiasm, many students 
abandoned their own tool-building efforts when they discovered that a 
poster progtam (Snoopy :atrylng a nicely formatted sign) already existed. 

Graphics students wrote procedures of analogous complexity 
(examples below) but producing results ^n the display screen often did 



10 HHH 
20 EEE 
30 LLL 
40 LLL 
50 000 
END 



partially quoted when involving the special character 



student' 



"//" (used by Logo to provide additional "real" blanks 



s minds: strings often appeared unquoted or 



125 



ERIC 



not provide the same reinforcement as producing hardcopy to take home. 
The plotter was late in arriving, and our attempts at photographs were 
poor since our borrowed camera lacked a proper hood attachment* 

TO DANCE TO WHEE TO CARDS 

10 POKE 10 FRONT RANDOM 10 SQUARE 

20 UNPOKE 20 RIGHT RANDOM 20 RIGHT 10 

30 RIGHT 90 30 WHEE 30 CARDS 

40 DANCE END END 

END 

Students sometimes forgot to provide input names in the ^DOUBLE* 
procedure or spelled them differently from occurrences in the procedure 
body; they put colons around the numeral 2 (^OUTPUT PRODUCT :NUMBER: 
:2:*), forgot the command for multiplying (should the name reflect the 
operation ('MULTIPLY') rather than the result ('PRODUCT')?), or squared 
the number instead of doubling it ('OUTPUT PRODUCT :NUMBER: :NUMBER;'). 
Since Logo accepts noise words such as 'OF' and 'AND', many students 
expected to be able to use "BY" in the division command used in their 
'UNDOUBLE' procedure. This led us to question the use of Logo noise 
words at all, and suggested that students should be able to add their 
own sets of noise words. Some examples of these problems follow. 



TO UNDOUBLE (missing input) 

TO UNDOUBLE IS TO TAKE HALF 

TO UNDOUBLE : THING OF : NUMBER: 

UNDOUBLE MEANS TO DIVID 

PRINT DIVIDE :NUMBER: BY 2 

PRINT DIVISION : NUMBER: :NU1'IBER: 

PRINT QUOTIENT :tnJMBER: DIVIDED BY 2 



OUTPUT QUO : NUMBER: BY 2 

OUTPUT QUO : NUMBER: :2: 

OUTPUT QUO :NUBER: : NUMBER: 

OUTPUT DIV 2 : NUMBER: 

OUTPUT QUO OF : NUMBER: 

AND :NUMBER: BY 2 
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The next problem In Part 6 was a functional relation taken from the 
preliminary test; It was also used In the Simper curriculum: 



"What function (rule) using only simple arithmetic, can you 
find which changes 



each of these numbers 

3 
4 
10 



Into each of these numbers 

. 15 
17 
29 



Write a procedure that uses this rule. (If you don't know 
the rule or how to start the procedure, ask a tutor)/' 



We hoped that students would use their 'DOUBLE' procedure in the 
solution: 

TO RULE : NUMBER: 

10 OUTPUT SUM 9 AND DOUBLE : NUMBER: 
END 



But those not using 'DOUBLE' often became entangled in the mysteries of 
nested expressions, noise words and syntax in trying to produce: 
'OUTPUT SUM :NUMBER: AND SUM OF :NUi^ER: AND 9'. Other examples 
are: 

OUTPUT SUM :1^UMBER: :NUMBER: 9 
OUTPUT SUM : NUMBER: : NUMBER: SUM OF 9 
SUM OF 9 TO THE PRODUCT OF :NUM: BY 2 



(missing a SUM) 
(SUM in wrong place) 



TO CORRESPOND 3 TO 15, 4 TO 17, 

AND 10 TO 29 

TO ADD : NUMBER: 

10 OUTPUT SUM DOUBLE ADD 9 

MULTIPLY :NUM: BY 2 
ADD 9 

MAKE PROD : NUMBER: AND 2 ANSWER 
OUTPUT SUM OF ANSWER AND 9 



(an interesting but 
illegal title) 



(unbounded recursion) 
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In the last two examples, students appeared to understand the "rule" but 
tried writing the expression on two sequential command lines, forgot the 
names of the 'PRODUCT* and 'SUM' operations, did not quote names or 
reversed the name and value Inputs to 'MAKE', 

In drawing complex pictures, students were encouraged to decompose 
these Into more basic geometric shapes. They were helped In writing 
programs to draw shapes of any size. In three of the following 
'RECTANGLE' examples (all from different students), errors Indicate that 
the students may be trying to give values to the procedure Inputs at 
define time; In addition, there Is a curious lack of the commands 
('FRONT') to do the actual line drawing • 



TO REC : LENGTH: : WIDTH: TO RECT : LENGTH: : WIDTH: 

10 PD 10 20 

20 : LENGTH: 20 50 

30 RIGHT 90 END 
40 : WIDTH: 

END TO RECT :LEN: :WID: 

10 OUTPUT RECT 6 3 

TO RECT :LEN: :WID: :200: :50: END 



The first problem In Part 7 was analogous to 'DOUBLE' for strings; 



"Write a procedure called AGAIN that doubles its Input word 
(Its Input Is a word), and outputs the resulting word. 

When you type this you should get 



P AGAIN "DOG" DOGDOG 

P AGAIN AGAIN "ALDO" ALDOALDOALDOALDO 

P AGAIN W "BL" "ACK" BLACKBLACK 

P AGAIN : EMPTY: 

P AGAIN 12345 1234512345 ' 



Errors In solving this problem (examples follow below) and other 
problems from this section Involve coordinating procedure Inputs, the 
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correct functional operations, and the 'OUTPUT' command. Students 
forgot to put Input names In the title, used literals In place of names, 
or used najnes different from those named In the title. For these 
latter, Logo happily supplies the default value EMPTY:' rather than 
complaining about an undefined variable. Inconsistently, undefined 
procedures are not defaulted to "no-ops", and a name and Its default 
Instantiation do not appear when the student requests a list of all the 
names In the workspace. Students sometimes substituted 'PRODUCT' for 
'WORD'; the noise word 'AND' appears In several contexts suspiciously 
like an Infix concatenation operator — another reason why default noise 
T^ords should be eliminated, certainly those which have a strong, clear 
meaning in natural language. 

TO AGAIN :W: 

10 OUTPUT WORD :W: :W: (a solution) 
END 

P "INPUT" @ W "INPUT" P WORD AND WORD 

P "WORD" PLUS "WORD" OUTPUT WORD OF "WORD" AND "WORD" 

OUTPUT PRODUCE :LETTERS: 2 :WORD: REPEAT 

OUTPUT :WORD: AND :WORD: :W: WORD :W: 

OUTPUT WORD :DOG: :DOG: 

OUTPUT INPUT :WORD: AND :WORD: AGAIN 

Students wrote procedures to return the second and third letters of 
a word. These were Intended as building blocks for a procedure called 
'SWITCH13' which would exchange the first and third letters of a word. 
Students often failed to break the problem into manageable parts and 
thereby notice that some of the components had been solved previously. 
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We were looking for solutions of the form 'OUTPUT WORD WORD WORD THIRD 
:W: SECOND :W: FIRST :W: BF BF BF :W: ' ('BF* is the abbreviation for 
'BUTFIRST*, 'F' is the abbreviation for 'FIRST*). Several students 
mentioned the input only once (i.e. 'OUTPUT W W W F BF BF F BF F BF BF 
BF :W:') — they may have believed that :W: was automatically 
distributed and that they need only mention it once. The following is 
typical of the half Logo, half English procedures which occasionally 
appeared. 



TO SWITCH 13 

10 THIRD : INPUT: 

20 FIRST : INPUT: 

30 PUT THIRD FIRST AND FIRST THIRD 
END 



Students in the teletype groups were asked to write a recursive 
procedure to type dashed lines where the "dash" could be any character. 
Simper students worked on a similar problem. The graphics students 
worked on a 'DASH' procedure with one input for the visible part and the 
other input specifying the gap length. Example attempts include: 



Since we did not teach about Logo's 'GOTOLINE' command, the example 
on the left must contain influences ('RUN' and 'LINE 15 DASH') from 
Basic or Simper. The 'DASH' procedure on the right does draw dashed 
lines, but the extra line 60 indicates that there is some doubt in the 



TO DASH 
10 RUN 

15 FRONT 100 

20 PENUP 

25 FRONT 10 

30 PENDOWN 

35 LINE 15 DASH 

END 



TO DASH :DIS: :TANCE: 

10 PENDOWN 

20 FRONT :DIS: 

30 PENUP 

40 FRONT :TANCE: 

50 DASH :DIS: :TANCE: 

60 DASH :DIS: :TANCE: 

END 
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student *s mind about how recursion works — perhaps she expected only 
three dashes to be drawn (e»g. by lines 10-40, 50, 60) ♦ 



Teletype students produced a diagonal dash program and tried a 
recursive procedure with a changing Input to do ripple printing, which 
Is similar to an earlier problem. I.e. move the first letter to the end 
of the word, repeatedly: BANANAS, ANANASB, NANASBA, etc. Graphics 
students wrote a procedure to bend lines (I.e. make polygons) with two 
Inputs: the distance the turtle moves and the angle to turn each time, 
and then modified It ('BD* below) to make spirals (they later made *BD' 
stop af tor some number of Iterations) . 



The 'SQUEER* procedure makes patteims of nested squares. Students 
enjoyed experimenting with different number inputs to these procedures. 
One frequent error was forgetting to specify all of the Inputs in a 
direct command or recursive call, especially when that input does not 
change: for example omitting the last :I: in line 30 of *BD\ One 
student defined the following unusual construct: 



She then typed *STEVE BD 17 16 48% which incidentally works because in 
attempting to bind STEVENS input, Logo runs BD and waits for a value, 
which never comes. We suspect that the student did not realize this; 



TO SQUEER :SZ: :TU: 
10 SQUARE :SZ: 
20 PENUP 

30 SQUEER DIFF :SZ: :TU: :TU: 
END 



TO BD :L: :A: :I: 
10 FRONT :L: 
20 RIGHT :A: 
30 BD :L: SUM :A: 
END 



• T • 



•T • 



TO STEVE :BD 17 16 48: 
10 :BD 17 16 48: 
END 
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trying 'STEVE' with a different call to 'BD', with 'STEVE' and 'BD' 
traced, would have helped correct this mistake. 



For an 'EVENP' procedure which returns "'TRUE'" if its number input 
is even, and '"FALSE"' if it is odd, students had trouble with 
distinguishing 'OUTPUT' and 'PRINT' and expressing numerical tests 
(infix expressions might be more natural). 'OUTPUT', from the 
students' point of view, was apparently not the best choice of words, 
hence we added 'RETURN'. One might also consider words li* i 'REPLY', 
which tend to better describe the message-sending/receiving activity 
going during Logo's evaluation. 



TO EVENP : NUMBER: 

10 TEST ZEROP REMAINDER : NUMBER: 2 
20 IFTRUE OUTPUT "TRUE" 
30 IFFALSE OUTPUT "FALSE" 
END 



(one solution: 
these three lines could be 
replaced by OUTPUT ZEROP 
REMAINDER : NUMBER: 2) 



OUTPUT "TRUE" IFTRUE DIVIDEND OF : NUMBER: 2 LEAVES NO REMAINDER 



IFEVEN P TRUE 
IFUNEVEN P FALSE 

OUTPUT "TRUE" IFTRUE EVEN 
OUTPUT "FALSE" IFFALSE ODD 

TO HORZDASH : PAPER: 
10 TEST ZEROP : PAPER: 
20 TYPE 

30 HORZDASH DIFF : PAPER: 1 
END 



P FALSE IF NOT DIVISABLE BY 2 
P TRUE IF DIVISABLE BY 2 



(result of the test is ignored) 



Students wrote procedures to type dashed lines and make their 
teletypes sound like ringing telephones; graphics students made the 
turtle dance by poking ('TURTLEPOKA') its head out on even degree turns, 
and pulling it in on odd degree turns. 
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Binary "life" (see Appendix 4) uses a Logo string of O^s and 1*8 
as a colony of reproducing creatures on the planet Binar, with each 
new generation appended to the colony based on the oldest (leading) 
generation which then dies* The colony becomes extinct if it ever fell 
below a certain critical size* This project was quite popular with 
students. They tried to predict which initial states would result in 
expansion, steady state or extinction. One student also experimented 
with changing the rules. 

Parts 9 and 10 contained numerous examples of projects combining 
most of the earlier concepts, but, unfortunately, few students started 
these sections; reasons include vacations, involvement with two 
languages and curricula (Groups I, II, and III), and other projects. 

Students embarked on several projects of their own choosing. A 
"Madlibs" program typed "story skeletons" with certain nouns, verbs, 
adjectives and adverbs supplied by the program user, often with 
hilarious results. The use of one procedure input per missing word 
worked well for small numbers of words but needed a more general scheme 
for prompting and obtaining values. In the days of pre-animation 
graphics, a launch procedure gave the illusion of a rocket trajectory 
by drawing and erasing a gradually shrinking, rising and tilting rocket. 
One ambitious student drew a pool table with pockets, cue stick, rack 
and balls. He then programmed a movie sequence for the break and 
several shots via * ZAP* -ping and redrawing appropriate parts of the 
scene. One graphics student abandoned his drawing activities for 
several days in order to make an elaborate poster saying "SIMPER IS 
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FULL OF SUDS". Another student produced what we thought was a novel 
approach to drawing a circle with a turtle: 



TO CIRC :RAD: 

10 FRONT SUM :RAD: 1 

20 PENDOWN 

30 BACK 1 

40 PENUP 

50 BACK :RAD: 

60 RIGHT 1 

70 CIRC :RAD: 

END 



In closing, we mention several examples of student behavior. 
One girl usually began her session by typing 'MAKE "GAIL OLDS" "THE 
GIRL THAT IS TYPING ON ME"'. Several of the graphics students spent 
the remainder of the morning on teletypes after their regular hour was 
done. Some students logged in on several terminals so that they could 
make posters while programming. General reactions to errors ranged 
from logging out (using 'GOODBYE' or their own logout or "selfdestruct" 
procedures) , to shifting tasks (trying familiar procedures they had 
written earlier), random typing (many "carriage returns" on graphics 
terminals eventually scrolled the text area, thereby erasing the error 
message), asking tutors for help, or trying to respond in an intelligent 
(although English) way. 



MAN STICK IT IN YOUR EAR 

man needs a meaning. stick needs a meaning. 

MAN DOESN'T NEED A MEANING, YOU DO TO INSERT 

SEE 

you are not on an imlac 

WHY NOT? WHEN I FINISH TYPING THIS LINE 

LINE YOU WILL REPEAT IT AFTER 

illegal mem alloc trap.. from 13125 YOU TRANSLATE IT INTO YOUR 

ILLEGAL MEN IN ALLOC TRAP MEMORY BANK 
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6^2 Evaluation of Simper and Logo 

As a result of the experiment, we have various modifications that 
we have made or would like to make tc the languages and devices used by 
our students • We will discuss these along with general commments about 
their pedagogical usefulness* 

Simper * First targets for change were obvious bugs and 
Inconsistencies In command evaluation and assembly. For example, 
* SCRATCH^ was modified to accept the general form for an address-range 
specification (e.g. ^SCRATCH 6:8^ has the obvious effect). ^SAVE^ and 
*GET* now accept the name of the file as an Input (e.g. ^SAVE GLOP*), 
resorting to the dialog mentioned earlier only when an Input Is lacking. 
A more subtle change was made to *SLIDE\ One student was frustrated 
when his memory space was effectively exhausted even though numerous 
holes existed between program segments. A forward ^SLIDE^ (e.g. ^SLIDE 
100:200^) now recursively squeezes out such holes to make formerly 
Impossible relocations possible. The user Is Informed of which holes 
disappear. 

In the Interest of making the name fit the action, ^FIX^ was 
replaced by *EDIT\ This was also done to reduce the language burden 
of learning both Logo and Simper. 

New operations and a new command were added* ^LEXOR^ gives a 
decimal version of "exclusive or" (Table II), ^ERROR^ tests for 
arithmetic overflows, ^lOT^ communicates with the Graphics program and 
the plotter, and ^NEWS^ gets the system time schedule and any new 
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information about Simper (or Logo). ^DIVIDE* was modified to set a 
flag, detectable by *ERROR*, on division by 2sero, instead of the 
previous and unusual skip-if-successful convent ion • 

The structure of the Simper machine itself was modified. Five- 
hundred memory cells and four registers (i.e. A, B, C and P) were made 
standard (with upper limits as shown in Figure 2) . This was motivated 
by students suggesting projects for which 250 memory cells would be 
insufficient. The additional register was added to make procedure 
calls more convenient, especially via a student-programmed stack. The 
changes were achieved by a generalized restructuring of the interpreter. 

Recommendations . Changes are relatively easy to make in Simper 
because it is written in a high-level language. An important 
improvement would be the simulation of a micro-coded machine with 
interrupt handling, so that students could be exposed to some aspects of 
modera machines. Simulated devices other than the turtle (e.g« a disc) 
could also be pedagogically beneficial. However, too many ''features" 
can be detrimental. Since one of the most valuable computational ideas 
is chat problem solutions can be broken logically into parts that are in 
turn realized by certain basic and sufficient abilities of some machine, 
the abilities chosen should not be too powerful. 

Perhaps the most beneficial results would be achieved by making the 
interpreter smarter and more congenial in terms of its responses to 
naive programmers. A first step would be a structured treatment of the 

or *HELP* command. Successive applications of this command in, 
say, an address field would obtain successively more detailed help about 

136 



address fields* In this respect, the interpreter would be more 
knowledgeable about itself. More general (and more difficult) powers, 
such as the ability to evaluate programs, would be of obvious value in 
counselling students. 

Except for a few run-time bugs introduced by the Sail compiler, the 
Simper interpreter proved remarkably durable under student use. No 
student ever lost his active memory or a saved program as a result of an 
interpreter fault. 

Logo. In our present version of Logo, changes such as editing 
error messages, adding new commands, and substantial changes to the 
parsing and naming schemes range from easy to painfully difficult. Had 
more resources been devoted to this project, we would have designed and 
implemented our own Logo interpreter in Sail. Integrating this with 
existing Sail software (i.e. train, graphics, animation) would provide 
greater accessibility to data objects such as snapshots and avoid the 
multiple- process structure of Tenex and the associated time penalties 
incurred in using graphics and animation. In addition, it should be 
easier to experiment with old and new features (e^g. parsing, filing 
and program analyzing) and to use this as a model for implementing 
subsets of Logo in other languages (e.g. Basic or Fortran) for users of 
other, smaller machines. Another option we considered was to modify an 
as yet unavailable interpreter (Manis, 1973) vnritten in Bcpl, which is 
generally machine independent. 

Recommendations . If ':X:' is to be analogous to 'VALUE "X"', then 
nesting of colons should be allowed. Additionally, a different sjrmbol 
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should be used Instead of colon to delimit place holders In procedure 
titles, or a different synonym for 'VALUE' could be chosen (e.g. "@") . 
Numerals should be disallowed as names. More fundamentally, we suggest 
that atom names and procedure names use the same dictionary and notation 
(e.g. 'A' could either stand for 'VALUE "A"' or call procedure 'A', as 
in Algol 60). Pedagogically speaking, any distinctions of program from 
data should be defined by the student and not be automatic. 

Command Evaluation . When a student types the 'MAKE' command but 
omits one or both inputs, Logo prompts for the missing inputs (after 
typing "NAME" or "VALUE" as appropriate) rather than yield an error 
message as is the case with all other commands. Control over 
evaluation and error handling must be more generally accessible in order 
to be a useful rather than an inconsistent feature. Commands for 
editing, erasing, listing and filing currently quote rather than 
evaluate their inputs (i.e. 'EDIT ROCKET' instead of 'EDIT "ROCKET"' 
thus disallowing 'EDIT :R: ' where 'VALUE "R"' is "ROCKET") A 
consistent, flexible scheme (assuming names and procedures share the 
same name table as suggested above) would allow only 'EDIT "ROCKET"' and 
'EDIT R'. 'EDIT ROCKET' could also be allowed if the user could make 
his own procedure definitions that quote or evaluate inputs at will — 
all in the interest of consistency, which is very important to naive 
programmers. A further simplification would result if one operation 
(e.g. 'DEFINE' or 'HOWTO') performed the functions of both 'EDIT' and 
'TO', since the only difference is the pre-existence of, or lack of, a 
definition. 
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Noise words should be eliminated unless they are under user 
control. Logo should emulate Lisp in returning values for all commands 
and perhaps printing these values at the top level rather than giving 
the message "THERE IS NO COMMAND FOR..." when a student forgets to 
precede a function call with a receiver for its reply. A user- 
controlled toggle for auto-value-prlnting would be a useful debugging 
aid. This would make 'STOP' and 'DONE' equivalent to 'RETURN ""'. 

Logo should allow multiple commands on a line, even though these 
would be more difficult to edit and might introduce ambiguity. Then 
the semicolon comment-toggle would truly make sense. 

Error Messages and Primitive Names . Synonyms for commands (e.g. 
'REPLY' or 'RETURN' for 'OUTPUT', and 'DONE' for 'STOP') have been added 
to clarify certain concepts. Error messages such as "OUTPUT CAN'T BE 
USED AS AN INPUT IT DOES NOT OUTPUT" have been edited. Misleading 
messages such as "OUTPUT CAN ONLY BE USED IN A PROCEDURE" require 
additional logic to determine context: in response to the situation of 
typing 'OUTPUT' as a direct command during procedure editing, the 
message should be that 'OUTPUT' cannot be a direct command and should be 
preceded by a line number. Error messages should not end with a "?" 
unless the interpreter is able to engage the student in a helpful dialog. 

Editing and Filing . One common desire was to change a line in a 
procedure with one rather than two commands — commands such as 20 and 
'EDL 20' typed at Logo's top level resulted in the messages "LINE 20 OF 
WHAT PROCEDURE?" and "EDIT WHAT? YOU ARE NOT DEFINING ANYTHING" which 
may have misled students into trying the following commands: 
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EDIT LINE 10 OF UNDOUBLE EDIT LINE 10 IN TRI2 

ERASE LINE 6 IN RECTANGLE P LINE 15 I.i STOP 

TO 35 OF RECTANGLE TO @35 OF RECTANGLE 
TO "35" OF RECTANGLE 

Since we view line numbers as an editing convenience for non-display 
devices rather than as necessary labels for controlling procedure 
evaluation, continued work with graphics terminals should Include 
experiments with different editors. 

Students often Included extra words (some which Logo used In 
messages) ) noise words, or expressions In commands such as ^EDIT^, 
*ERASE', and 'LIST', which do not obey the general Logo evaluation 
scheme; hence, error messages were often puzzling. 



EDIT TO EVENP EDIT :XI: 

you can't edit that. you can't edit that 

ERASE ;XI: ERASE TO SQUARE 

erase what? erase what? 

END LIST ALL FILES 

again defined list all what? 
UNDEFINE AGAIN 

undeflne needs a meaning. LIST NAMES 

something missing for list. 

LC OF FILE OF MARTA LIST ALL THAT WAS DONE TODAY 

of can't be a file name list all what? 

GET GAIL FILE GET FILE PC 136 VOWELP 

file can't be a file name. file can't be a file name. 



As a convenience. It might be helpful to allow some default 
applications of operations like 'LIST'. For Instance, when 'LIST', 
'EDIT', 'ERASE' oi 'EDIT LINE xx' Is typed with no Input, the default 
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Input would be che name of the last procedure 'END'ed oz the last 
procedure In which an execution error occurred • 

The distinction between what is in Logo's immediate memory 
(workspace) and what Is on secondary storage (file entries) Is confusing 
even to adults. By saving an entire workspace on an "entry", it is 
fairly easy to 'GET' everything back at a later time. But since the 
workspace could contain tne appended results of several 'GET's from 
other entries (from other people's files too), there Is often 
unnecessary duplication in 'SAVE's. One should have the ability to 
save partial workspaces (groups of procedures) on entries. 



We found examples of student typing, some almost verbatim from the 
cuiriculum, which we might expert a reasonable computer-based tutor to 
be able to handle^ The naive approach of merely automating a 
pjcogramming cutTiculum (such as ours) by typing text at the student will 
accomplish lictie in dealing with su:.h questions. We believe that the 
language Intecpretex should "knov^" something about what concepts and 
problems the cuiriculum Is presenting and the intents of procedures the 
student Is writing* 



SAVE GAIL TRIANGLE 
SAVE GAIL RECTANGLE 
SAVE GAIL REPEAT 



(this replicated Gall's workspace 
in three separate file entries) 



SAVE LIZ D AND UD AND SQUARE 



(Liz wanted to save individual 
procedures on separate entries) 



HOH MANf INPUTS DOES ''MAKE" HAVE? 



".3 REQUEST A LIIERAL'? 
iitecal needs a meaning. 
W ir DOESN'T 
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HOW MANY INPUTS DOES PRINT HAVE 
IS "GEORGE" A WORD? 



The ability to answer these questions is easily given to Logo because 
the subject terminology (perhaps excepting "literal") is Logo's. 

Since Logo already checks procedure lines for matching quotes and 
colons at the time they are typed, it would seem advantageous to report 
other kinds of syntax errors at "def ine-time" rather than at "run-time". 
For example, erroneous number of inputs for primitive commands and user 
procedures, and undeclared procedures or names (not defined globally 
or in the procedure's title) could be reported after every line typed, 
before taking the student out of "editing mode", or upon request. The 
student can act on these suggestions and make further editing changes, 
execute the partially defined procedure while still in editing mode, or 
exit to work on something else. Although this would be of little help 
in detecting semantic errors, it could serve to minimize the amount of 
time students spend in discovering and correcting sjmtax errors one at a 
time. 

6.3 Implications for Language and Curriculum Design 

Reports of tutors about student involvement in different parts of 
the curriculum and their own projects, real or planned, led us to make 
curriculum changes involving the order of the concepts presented and 
techniques for explaining certain concepts. For example, names were 
viewed as belonging between literals and procedures in complexity, and 
as prerequisites for procedure inputs and list-like data structures* 
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For Simper, most changes centered upon better motivations for: 
context, sequential execution, addressing and assembly language. The 
machine'? language of numerals would be taught before assembler syntax 
so that students would grasp the latter^s reason for existence as well 
as its structure. The fact that different languages are appropriate 
for different interactions with Simper would be exploited in teaching 
about computational context. The intercommunication of instructions 
(e.g. via the repisters) within programs would also be treated in terms 
of context* 

We found that students were not particularly motivated by Logo-Part 
4 because, for all their efforts, only a few strings appeared on their 
terminals. Introducing the turtle commands in the context of the first 
procedure example would have allowed students to start editing and 
saving their initial pictures rather than using tl less enduring direct 
commands. As a result, names should be introduced first when 
procedures need them as inputs (formerly Part 6), and procedures should 
be introduced immediately after literals. 

If testing had been introduced earlier than Part 8, where its chief 
use wss to provide stopping rules for recursive procedures, students 
could have embarked earlier on their own projects, e.g. games like 
Blackjack and guessing numbers. This also has the advantage of not 
compounding testing with already difficult concepts behind recursive 
procedures with changing inputs. 

The graphics curriculum must provide a more clear-cut case for the 
advantages of graphics. By replacing the numerous teletype examples by 
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problems using graphics and animation, while maintaining a parallel 
ordering of concepts, results of comparing teletype and ^^.raphics 
curriculum can be more meaningful; in addition, two separate but 
parallel problem domains can provide for interesting testing of transfer 
for students from each curriculum. The curriculum can be enhanced by a 
computer-based tutor's use of graphics in presenting examples (one use 
is discussed below) and providing editing and debugging facilities. 

The curriculum format of path pointers, questions, problems and 
things to try was generally well-received by students. Certain 
connecting ideas or processes such as how expressions are evaluated and 
how procedure evaluation proceeds are difficult to sequence on paper, 
and the flowchart-like diagrams with boxes and arrows we tried were not 
particularly effective. The younger children had especial difficulty 
with these artifices, for the same reasons they had trouble with the 
candy-machine problem on the preliminary test. Good yet static 
representations of essentially dynamic processes are hard to come by. 
The "brothers" with knowledge clouds did test understanding when some of 
their states were left blank, but were of little help in mapping this 
understanding into a Logo procedure. One possibility is that Logo 
could graphically simulate some of its own internal workings* As an 
example of this idea, a film animating the evaluation of a Logo 
procedure has been done by Ron Baecker and students at the University of 
Toronto (Baecker, 1974). 
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7 Final Comments 



Having modified both curricula and Interpreters and gained 
confidence on the extent to which the preliminary tests predict success 
In the original curriculum, we proceeded to repeat the experiment with 
smaller, better controlled groups of students and more uniform tutoring. 
Analysis of this second effort, and a more thorough study of Groups I, 
II and III of the experiment we have been discussing, will appear In a 
separate report (Cannara, 1975). 
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Appendices 

The appendices included here pertain to the summer experiment of 
1973. The states of Logo, Simper and the curricula are reflected here 
as they were during that experiment, unless noted otherwise. Some Logo 
operations fit into none of the following appendices, so they are 
included here. 

Miscellaneous IMSSS Logo Primitives 

Any abbreviations are included beneath the full operation names, 
the number of inputs (arguments) required is noted in parentheses with 
the description of each operation, and indicates operations which 
were implemented after, and partly as a result of, the experiment 
discussed in this report. 



ASCII (1 -input operation) the input is the octal ASCII code of the 
character to type, e.g. ASCII 10 types a backspace 

ASKCHAR (1 -input operation) return a character from the terminal (the 
ASKC input is the number of seconds to wait before returning : EMPTY: 
if nothing is typed, see ASK) 

ASSIGN $ equivalent to MAKE (not implemented) 

BLANK (0-input operation) equivalent to TYPE : BLANK: 

BREAK (0-input operation) interrupt program execution as if CTRL-G had 
been typed (see GO, CANCEL) 

DEFINE $ equivalent to TO (not implemented) 

DONE $ equivalent to STOP 

HOWTO $ equivalent to TO (not implemented, but TO could be HOWTO's 
abbreviation) 

RAND (2-input operation) return a random integer from the range: 
(first input, second input) 
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REPLY $ equivalent to OUTPUT (not Implemented) 

REQUESTCHAR (0-input operation) return a character from the terminal 
RQC (see REQUEST) 

RETURN $ equivalent to OUTPUT 

SAMEP $ (2-input operation) equivalent to IS 

SAY (1 -input operation) audio system speaks a word or sentence, 
spelling any words for which it has no unitary, prerecorded 
sounds 

VALUE $ (1-input operation) equivalent to THING 

WAITM (1 -input operation) the input is the number of milliseconds to 
wait (not very accurate when the Tenex system is busy, see WAIT) 



Appendix 1; Graphics 

In this appendix, we describe in some detail the two types of 

(R) (R) 

graphic devices available to Logo users: the TEC^ ^ and IMLAC 
displays. Tables of the relevant Logo operations are included. 
IMSSS Logo is aware of the various types of terminals available to users 
and so can correctly execute some operations in more than one way, 
automatically producing an effect appropriate to the device at which the 
user happens to be (e*g. *LEFT' works for the TEC, the IMLAC and other 
devices. Appendix 2). In the following tables, any abbreviations are 
included beneath the full operation names, the number of inputs 
(arguments) required is noted in parentheses with the description of 
each operation, and indicates operations which were implemented 
after, and partly as a result of, the experiment discussed in this 
report. 
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1.1 TEC^^^ 



The TEC Is a raster-scan (video) display whose screen Is refreshed 
from a shift-register memory. It cannot be made to draw lines, but It 
possesses extensive abilities for editing the text appearing on Its 
screen* Under program control, these abilities are accessed by sending 
certain ASCII characters (some are "control" characters, some are lower- 
case) to the device. The user's typing Is restricted to upper-case. 
The abilities thus available to a Logo user are described In the 
following table, after which a sample Logo program that simulates an 
olevator Is Included. 

IMSSS Logo TEC ^^^ Primitives 

BLINKOFF (0-lnput operation) terminate blinking region at cursor 

BLINKON (0-lnput operation) start screen blinking to right of and below 
cursor 

BOX (0-lnput operation) type a "box" character 

CLEAR (0-lnput operation) clear the screen and then HOME 
CS 

DELETECHAR (0-lnput operation) erase character at cursor position and 
DC move the rest of line left one character 

DELETELINE (0-lnput operation) erase line cursor Is on and move lower 
DL lines up one line; move cursor to beginning of the line 

DOWN (0-lnput operation) move the cursor down one line (wraparound 
from bottom to top of the same column) 

ERASEDOWN (0-lnput operation) erase the screen to right of and below 
EEOP cursor 

ERASERIGHT (0-lnput operation) erase rest of line to right of the 
EEOL cursor 

HOME (0-lnput operation) move the cursor to the upper left corner of 
the screen (0,0) 
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INSERTCHAR (0-lnput operation) insert a blank character at cursor 
IC position and move rest of line right one character 



INSERTLINE (0-lnput operation) Insert a blank line at cursor position 
IL and move lower lines down one line (last line Is lost) move 

cursor to the beginning of the line 

LEFT (0-lnput operation) move the cursor left one character 

(wraparound from left edge to right edge of row abovej and from 
top left corner to bottom right comer) 

MOVEXY (2-lnput operation) move the cursor to absolute screen position 
(the column (first input) is between 0 (left) and 79 (right), 
the row (second input) is between 0 (top) and 23 (bottom)) 

RIGHT (0-lnput operation) move the cursor right one character 

(wraparound from right edge to left edge of row below, and from 
bottom right comer to top left corner) 

UP (0-input operation) move the cursor up one line (wraparound from 

top edge to bottom of same column) 



The following is a listing of a Logo elevator simulator that uses 
some of the operations above to "draw" and move a 10-story elevator on 
the TEC screen. 'START* initiates the simulation. 



TO START 

10 CLrjVK 

20 KAKB "capacity" 10 
30 yjyKC "FLOOR 10 
40 yJSt ][CFST£R" 36 
50 PAKE "bOFTCm" 27 
60 TWlt 
70 SKIf 

ftO MAM "CyiCX 250 
90 HAKE Slot! ^00 
100 HAKE "floor RAJID 1 10 
110 MAKE "levator" RA^D 0 tCAPACITYl 
120 KUN 
IND 



I InltiAllstt th« •itnuUtlon 

; ftl<tvator't tlx* 
; building's h«l9ht 



; put p«opl« on th« floors 



tPU)ORt tEXSVAIOitt 



TO RUN 

10 TEST 2ER0P SUM THIU'G WORD FLOOR 
20 imUC SHCV :CUXCKt FLOORPOSITION 
30 BELL 

40 IFKALSE SHOW tSLOtft FLOORPCSITION 
SO RIGHT 
60 USLOAO 

70 MOVEXY SUM tCEtTTERt 1 FLOORPOSXTXON 
80 LOAD . 

90 MAKE ELEVATOR SUM tGOTON: DIFFERENCE sELEVAIOh: :0010FF: 
100 MAKE WORD 'FLOOR" tFLOO:^: 

DiFFHREh'CE SUM THING WORD FLOOR** iFLOORt tGOTOFF) tCOrOkSt 
110 MAKE "X" BUTFIR5T DIVISION KANDOK 2 
120 TEST ZERO? tXl 
130 IFtRUE MOVroOWN 
140 IFFALSC MOVCUP 
ISO SKIP 
160 RUH 



TO PEOPLE 

10 TEST ZEROP jFLOOR: 
20 IFTRUE STOP 

30 MOVEXY tCEKTER: FLOORPOSITION 
40 TYPE V 

50 MAKE WORD "FL00R"^:FL00R: RANDOM 
60 FOLKS.TKING WORD FLOOR :(LOOR: 
70 MAKE FLOOR** DIFFERENCE tFLOOR: 1 
80 PEOPLE 
END 

TO FOLKS tN: 
10 TEST ZERCP tN: 
20 IFTR'JE STOP 
30 TYPE i" 

40 FOLKS DIFFERENCE :N: 1 
END 
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TO rtOORPOSXTZON 

10 OUTPUT DXFfERENCS tiOTTOHt PRODUCT 3 trLOORt 



TO SMOU tTlMEs tPOSZTZOHt 
10 RESET IFOSITXONI 
20 »0X 

40 FOLKS t ELEVATOR t 
40 BOX 

70 VAZTM iTXKEt 

•0 RESET tPOSXTXONi 

90 &LAHKS SUK 2 tELCVATORt 

END 



) diapUyi th« •l«v«tor 

t «nd thoi« in It 
I for « llttX« 
t th«n •!«>•• It 



TO UNLOAD 

10 MAKE "OOTOrr RAMD 0 lELEVATORl 

20 GETOfP tGOrOff I 

END 

TO LOAD • • 

10 HAKE "COTOH* RA«D 0 laNIKUK THXWG WORD fLOOR JfLOCRl 

SUK tOOTOkTl DXrrERttlCE iCAVACXTYl itLEVArORI 

20 GETON tGOTONt 
EKD 



TO HOVEOOrfN 

10 TEST ECUALP tfLOORl 1 
20 XtTRUE hOVEUP 
30 XFTRUE STOP 

40 SHOW lOUICKl SUK KLX>itP0SXT10N 1 
» KAKE FLOOR Dl*'FEREKC2 ifLOORl 1 
END 

TO HOVEUP 

10 TEST EQUALP t FLOOR! 10 
20 XFTRUE KOVEDOWN 
30 XFTRU£ STOP 

40 SHOW iQUXCKi DXFFEREKCE FLOORPOSXTXCN 1 

iO KAK£ FLOOR SUK tFLOORt 1 

END 

TO RESET tYt 

10 KOVEXY DXFFEREJICE {CEKTERI SUH 2 lELEVATORl |Yt 
END 

TO ELANKS iNl 
10 TEST ZEROP iNt 
20 XFTRUE STOP 
30 BLANK 

40 BLANKS DXFFERENCX iKl 1 
END 

TO OBTOPF iNl 
10 TEST 7.ER0P I Hi 
20 XFTRUE STOP 
30 XNSERTCKAR 
40 TYPE T 

50 GBtOFF DXFFERENCB iNl 1 
BND 



TO GETON iNl 

10 TEST ZEROP tNl 

30 XFTRUE STOP 

30 DELETECKAK 

40 GETON DIFFERENCE tHi 1 

BND 
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1.2 IMLAC 



(R) 



The IMLAC is a stand-alone computer with display capabilities which 
allow it CO act as a local processor for Logo graphics commands. We 
first present two tables of the relevant Logo operations. Any 
abbreviations are included beneath the full operation names, the number 
of inputs (arguments) required is noted in parentheses with the 
description of each operation, and indicates operations which were 
implemented after, and partly as a result of, the experiment discussed 
in this report. The first table describes the animation added after 
the experiment. 

IMSSS Logo Animation Primitives $ 



ENDSNAP (0-input operation) finish defining the current snapshot, and 
ENDS wipe the screen 

ERASESNAP (1 -input operation) escape from snapshot in progress (after 
EKS SNAP, but before ENDSNAP) and reclaim drawing space and snap 

number; for snapshots which have been defined, ERASESNAP 
erases only the snapshot number (see WIPESNAPS) 

MOVESNAP (2-lnput operation) the first input Is a sentence of "object" 
MOVS numbers (see PUTSNAP) ; the second input is a sentence of the 
relative distance and angle to move each object respectively 
(when "R'' precedes the first object number, the sentence is 
interpreted as pairs of relative x,y distances to move each 
object); MOVESNAP returns a sentence of the new absolute x,y 
cooTidinates for each object; automatic wraparound occurs near 
screen boundaries (see WRAP) 

PUTSNAP (2-input operation) the first input is a sentence of pairs of 
PUTS snap and object numbers — a zero object-number means create 

a new object; an object number between 1 and 100 may create or 
redefine an objec;t; the second input to PUTSNAP is a sentence 
of pairs of absolute x,y coordinates for locating each object; 
PUTSNAP returns a sentence of the object numbers used (see 
MOVESNAP); to erase an object, redefine it to be an empty snap, 
i.e. snap 0 01 any other undefined snap 
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SHOWSNAP (1 -input operation) show a snap (the input number) at the 
SHOS current turtle location 

SNAP (1 -input operation) wipe the screen, and create a "snapshot" 
(the input number) out of the turtle commaads that follow; 
presently ZAP does not work within snaps 

WHATSNAPS (0-input operation) return a sentence of the currently used 
WHAS snapshot numbers 

WIPESNAPS (0-input operation) wipe the screen and erase all snapshots 
WIPS and objects 

IMSSS Logo Turtle Graphics and Plotter Primitives 

Some of these operations may be used to control both an IMLAC 
display and a Hewlett-Packard model 7202A XY plotter. The letter "P" 
indicates that an operation is implemented for the display and the 
plotter, while indicates an operation that usually was not 
introduced to students* 

ARC P* (2-input operation) the first input is the radius (positive 



input makes the turtle go forward) ; the second input is the 
amount of arc to draw (positive is leftward) ; the chart shows 
the four different arcs for different signs of the inputs: 



ASETX P* (1 -input operation) move the turtle to absolute x (the input 
number) , y remains the same 

ASETXY P* (2-input operation) move the turtle to absolute x (first 
input), y (second input) (see RSETXY) 

ASETY P* (1-input operation) move the turtle to absolute y (the input 
number) , x remains the same 

BACK P (1-lnput operation) move the turtle back (the input number is 
the distance, see FRONT) 

CLEAR (0-input operation) clear the text area of the screen without 
erasing the turtle picture 



r a 



r a 
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COMPRESS * (0-input operation) compress IMIAC display lists to recover 
more drawing space (only worthwhile if a picture has many 
short (less than 1 inch) lines), ZAP will not work on 
compressed pictures; if memory space is exhausted during a 
turtle command, the message: "DO YOU WANT TO COMPRESS THIS 
PICTURE? *" will appear; typing "YES" makes compression occur 
and drawing will continue if enough space is recovered 

FRONT P (1 -input operation) move the turtle front along its current 
heading (the input number is the distance, same as BACK with a 
negative input) 

HERE P* (0-input operation) return the sentence of the turtlo^s 
current position and heading: x, y, angle 

HIDE (0-input operation) make the turtle disappear (see SEE) 

HOME P (0-input operation) move the turtle to home (see SETTURTLE); 

change only position and headiag (not pen, head, or visibility) 

LEFT P (1-input operation) rotate the turtle left (counterclockwise 
the input is the number of degrees, same as RIGHT with a 
negative input) 

PENDOWN P (0-input operation) put the turtle* s pen down so that when the 
PD turtle moves, it leaves a trace 

PENP P* (0-input operation) return "TRUE" if the turtle ^s pen is 
down, "FALSE" if it is up 

PENUP P (0-input operation) put the turtle's pen up so that when the 
turtle moves, it leaves no trace 

PLOT P (1-input operation) direct turtle comands to the plotter 
(input is the system's "tty" number for the plotter) 

POKE (0-input operation) poke out the turtle's head (see UNPOKE) 

RIGHT P (1-input operation) rotate the turtle right (clockwise, the 
input is the number of degrees, see LEFT) 

RSETX P* (1-input operation) move the turtle relative to its x 

position (the input is the x distance) , y remains the same 

RSETXY P* (2-input operation) move the turtle relative to its x,y 

position (the first input is the x distance, the second Input 
is the y distance) (see ASETXY) 

RSETY P* (1-input opetation) move the turtle relative to its y 

position (the Input is the y distance), x remains the same 

SEE (O-input operation) make the turtle appear (see HIDE) 
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SETHEADING P* (1 -input operation) set turtle to a specified angle (the 
SETHD input number is degrees) 

SETSCALE P* (1 -input operation) set the display scale for turtle units 
units per inch (the input number) 

SETTURTLE P* (1 -input operation) the input is a sentence of three 
numbers; the first number is turtle units per inch (see 
SETSCALE); the location of "home" is defined by the number 
of inches to the right (second number) and above (third 
number) the lower left comer of the screen, e.g. SETTURTLE 
"100 4 4" (the first turtle command causes this as default) 
sets a scale of 100 units per inch with home at the center of 
the screen 



THERE P* (1 -input operation) the input is a sentence of three numbers: 
X, y, and angle (see HERE); equivalent to using ASETXY on the 
first two numbers, and SETHEADING on the third number, e*g. 
THERE "0 0 0" is equivalent to HOME 

UNPLOT P (0-input operation) direct turtle commands to the display, and 
release the plotter for others to use 

UNPOKE (0-input operation) pull in the turtle *s head (see POKE) 

WIPE (0-input operation) clear the turtle area of the screen; move 
the turtle to home with PENDOWN 

WRAP P* (2-input operation) the first input is a sentence of the low 
and high x values to use for the screen boundaries (defaults are 
"-400 400"), the second input is similar for y; line clipping 
and wraparound (for MOVESNAP) occur at these boundaries 

ZAP (0-input operation) erase last turtle move with pendown or 
last series of consecutive moves with penup 

ZIP (1 -input operation) the input is the number of turtle moves 
to ZAP 



The IMLAC PDS-1 is a stand-alone computer with two processors. 
One processor is a general-purpose, 16-blt machine, the other is a 
display processor that refreshes the PDS-Vs screen 40 time^ per second 
from a display list held m memory. Either processor may access memory 
by "stealing" instruction cycles from the other ^ The PDS-1 provides a 
screen resolution of approximately 96 points per inch. The screen can 
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be viewed as a mesh of overlapping character "boxes", each approximately 
5/8" square. Drawing lines across box boundaries requires either 
"long-vector hardware", or absolute or relative repositioning into an 
adjacent box before drawing can continue. Relative repositioning 
usually consumes more memory space, so we have used it only for drawing 
"snapshots", (i.e., translatable picture subroutines). The PDS-ls at 
IMSSS have only 4K of memory, and lack hardware for: multiplying, 
dividing, drawing long vectors, picture rotation, scaling, and 
translation. Furthermore, they use only one register for calls to 
display subroutines, which prevents the nesting cf snapshots (newer 
models have "pushdown stacks") . To circumvent some of these 
difficulties, Sailogo compiles line segments, repositionings and picture 
subroutines into buffers of command words, word counts, addresses, and 
data (i.e., PDS-1-code display lists) and sends these over a 9600-bits- 
per-second line to a program (Graphics), running in the user's PDS-1, 
that realizes Logo's graphic abilities. The program also scrolls the 
user's typing and returns transmission-error ("checksum") information to 
Sailogo. An organizational map of the PDS-1 s memory, as defined by 
the Graphics program, apr^ears on the following page; a sample Logo- 
graphics program follows that. 




* We are grateful to John Prebus for his help with the IMLAC graphics 
programming. 
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executive program (Graphics) > 

buffers and text display lists 
character display subroutines 
user display space (2048 words) 

turtle display subroutines 

+ > head 

+ > pendown 

I V 

H > penup 

V 

< body 



40 Hertz clock interrupt 
starts display program, 
executive continues 



display position to home < 

<display jump to user picturelist 



display no-op (shows turtle) < 

I or display halt (hides turtle) > f 

V I 
-<show pen (up or down) and body 

I / \ 

+'>di3play position to turtle head | STOP | 

\ / 
+ <show head 

I 

display halt (end of display program) > f 



user display subroutines: < 

"character mode" increments and relative 
positionings and a display subroutine return > — f 



+ > user plccurelist: a stack of "display cells" 

where a display cell consists of 



"character mode" increments 
and absolute positionings 
or 

an absolute positioning 
or 

an absolute positioning and 
display subroutine jump > — 



followed by a display no-op <~ ^ 

or 

display jump cc show turtle (last cell) >- 
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The following is a listing of a Logo-graphics program which uses 
the IMLAC display to simulate a helicopter. The helicopter may be 
"flown" on the screen in response to a user's typing (e.g. "U" adds an 
upward increment to the helicopter's velocity, "H" makes it hover). 
The program was written by a student from the experiment discussed in 
this report. It is featured as part of the movie mentioned in Section 
2.2.2. The student required some help to organize his ideas in terms 
of a sensible control structure. The procedure 'COPTER* initiates the 
simulation, 'FLY' maintains it and interacts with the user. 



TRUE 



TO CCPTER 
5 VXPtSNAPS 
10 SNAP 1 
20 TL\XR 
30 ENwSNAP 
50 KAKE *XVEL2 0 
60 KAKE "WEL^ 0 

70 HAKE Urate s 

75 MAKE "ground" 
flO SNAP 2 
90 BUiDZ 340 0 
too n^DSHAP 
110 SNAP 3 
120 ELADE 150 30 
130 ENDSNAF 
140 SNAP 4 
150 BLADE 60 70 
160 ENDSNAP 
170 SNAP 5 
180 BLADS 30 90 
190 £f;DSNAJ> 
155 SNAP 6 
200 EAHTH 370 
210 EnDSNAP 

SNAP 7 
230 EARTH 300 
240 EiSDSNAF 
250 SNAP e 
260 EARTH 200 
270 ENDSNAP 
272 SNAP 9 

276 i;ndsnap 

280 IGNORE PUTSNAP "l 1 



1 lnltlnXiz«« •inuXatlon ^nd dr*w« o«*d«d •n«p«ho(.« 




0 -250 



2 pX«c« th« h«Xlcoptcr on acrMn 



290 RZDE 
295 CtEAR 
300 FLY 
END 



t turtX«'» votK !• don« 
I taJc»*o££t 



TO EARTU tSXZEi ; dr«w» vltwt of grourvi 
10 FRONrr iSXZEi 
20 RXGKr 120 
30 PROKT iSXZEi 
40 RXCHT 60 

50 F^ONT 8UH tSXZEi gUOTIEyT tSXZEt 2 
60 UtGHT 120 
70 FROST sSXZEt 
eo .ftXGHT 60 

90 FRONT QUOTXENr (SiZEt 2 
END 
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TO FLYER 

1 PENUF 

2 BACK 21 

3 FENDOVD 

4 FRONT 21 
10 RIGHT 90 
20 FRONT 20 
30 LEFT C6 
40 rnoNT 30 
50 FEMUP 

40 RIGKT 90 
70 FRONT 80 
BO LEFr 90 
90 PE.S0OVH 
100 ARC 40 180 
110 PENUP 
115 LEFT 90 
120 FROST 60 
130 RIGHT 95 
140 PESDOVN 
150 FRONT 60 
160 RIGHT 70 
170 FRONT 60 
180 LEFT 70 
190 FRONT 110 
200 PEN'JP 
210 RIGHT 60 
220 BACK 20 
230 PP~NDOWN 
240 FPONT 40 
2t>0 PES'JP 
260 BACK 20 
270 LKFT 60 
280 PKNDOVN 
290 Ff'CsT 15 
300 KZ^Ht 40 
31 0 FhONT 30 
320 RlGdT 60 
330 FRONT t> 
340 RIHHT 115 
34S FKCI«T 40 
3iO Lfckt 42 
360 FkOWT 140 
370 LhFT 92 
360 tO.M( 20 
yiO PW< IP 
400 BACK eo 
4fO MCKT 
420 kH'itiT 10 
410 LM'T 90 
440 BA'.Y. 7'^ 

4fn> Pisri^S 
470 AKO 100 

4F0 lyr: 90 

490 >Kx^%T JO 
500 l^iT ''>0 

sio rsN.? 

520 FROM 50 

530 lkf: 90 

540 FROST 60 
!>50 KliSrr 180 
560 PFNrCWN 
570 FRONT 45 
5G0 Ite^ 50 
590 FRO^T 25 
600 RIGnT 145 
610 PENV? 
620 FROST 90 
630 LEr*T 90 
640 FRONT 15 
650 PEN? OWN 
660 FROST 25 
670 BACK 25 
680 FROST 25 
690 LEFT 90 
700 PACK 10 
71 C FROST 70 
720 LEFT 95 
730 FROST 20 
740 BACK 20 
750 KIGKT 95 
760 FROST 10 
770 ARC 35 45 

E^a> 



t artws th« h«Ilcopt«r 



VO BLADE tLENt tROTt 

10 PESUP 

20 LEFT jROTt 

30 BACK CUOTIEffT iLEHl 

40 PEUOG^ 

50 FROtTT ihZHt 

END 



I draws rotor blad«s 




TO FLY 

10 CHECK 
20 MAKE AIR 
30 TWIRL 2 5 
40 TEST tGRO'JNO: 
50 IfTRU?, SUkPOO^iU 
60 IFFALoB SUC^.LAHD 
70 FLY 
ZSD 



; manages th« h«Ilcopt«r's ootlon 
M0VESN.\P "ri 2" bENTENCES tXVELj jYVELt tXVELt tWBLt 
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\ 9lv«s th« ''pilot** control 

SUN lYVEL: tRATIt 

DIFFERENC£ jYVELl JiUTEt 

OIFPERENCE JXVELl 

SUK tXVELt sRATBt 



"true" 



TC CHECK 

10 HAKE "key* ASKCHAR 0 
20 Ti:sT IS iKF.Yl "u" 
30 imU£ KAKE "YVEL" 
40 TEST IS I KEY! "o 
50 IFTaUE MAKE "yVLL* 
60 TESr IS iKEYi 

70 IFTRUE MAKE XVn." OIFPERENCE JXVELl iRMti 
60 TEST IS iKEYl R" 
•0 IFTRUE MAKE "XVEL" 
100 TEST IS I KEY: '.-i** 
110 IFTRUE MAKE "XVEL* 0 
120 irrRL'E MAKE "WEL* 0 
130 TEST IS JKEY£ "? 
150 IFTRUE MAKE GROUND* 
160 TEST IS jKEYt "O** 
170 irXRUE MAKE GROUND* 
£ND 



TO TWIRL tBSt tZSt ; twlrl» th« tOtOt 

10 TESr GREATER? thSi ttSt 
20 IFTRUE STOP 

30 IGNORE PUTSNAP SENTENCE {BSt 2 tAIRt 

40 rifIRL SUM (BSt 1 tCSt 

END 



TO SNAPDOWN ^ 
10 TEST LESS? FIRST BUTFIRST tAIR: (-200) 
20 IFTRUE IGNORE PUTSNAP "6 3 0 -50 
25 IFTRUE STOP 

30 TEST LESSP FIRST BUTFIRST iAIR: 200 
40 IFTRUE IGNORE PUTSNAP "7 3 "O -100 
50 IFTRUE STOP 

60 TEST LESSP FIRST BUTFIRST tAIRt 400 
70 IFTRUE IGNORE PUTSNAP "8 3 0 -200' 
END 



t mAX«« th« tArth roc«;2« 



TO SHOW. LAND 

10 IGNORE PUTSNAP *5 3** **0 -350* 

20 TEST LESSP FIRST iJUTFIRST lAIRt AND 

40 IFTRUE HAKE '*YVEL** 0 

EKD 



t ground l«v«l 



150 
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Appendix 2; Controllable Devices 

In this appendix, we describe some electro-mechanical devices which 
IMSSS Logo now controls. Tables of the relevant Logo operations are 
Included with the discussions of the devices. IMSSS Logo Intelligently 
uses Its knowledge of the type and location of any terminal that the 
user might pick. For Instance, the physical Train may be controlled 
only from a terminal within sight of the layout; picking another 
terminal causes Logo to simulate the train instead. 

2.1 Robot Turtle and Music Box 

A controllable robot "turtle" is available from General Turtle 
Incorporated, Cambridge, Massachusetts. An interface allows the robot 
to be controlled by sequences of characters (ASCII) sent to it over a 
30-characters-per-second line from Logo. The interface provides 
several "ports" to which one may connect turtles and/or "music boxes" 
for multiplexed (seemingly simultaneous) operation. The music box, as 
its name suggests, allows Logo programmers to write programs which play 
or generate musical compositions. It is an output device and returns 
no information to the controlling program. The turtle, on the other 
hand, does return some information (e.g. 'TOUCHLEFT') which allows one 
to write programs that adapt to the turtle's environment* In the 
following tables, any abbreviations are included beneath the full 
operation names and the number of inputs (arguments) required is noted 
in parentheses with the description of each operation. 
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IMSSS Logo Robot Turtle Primitives 



Some operations have the same effect as for the IMLAC graphics 
Turtle (see Appendix U2)« indicates that the operation usually 

was not introduced to students • 



BACK (1 -input operation) mo^^e the turtle backward (the input value is 
the distance, see FRONT) 

FRONT (1 -input operation) move the turtle forward along its current 
heading (the input value is the distance, same as BACK with a 
negative input) 

LAMPOFF (0-input operation) turn off the turtle *s headlight 

LAMPON (0-input operation) turn on the turtle *s headlight 

LEFT (1-input operation) rotate the turtle left (counterclockwise, 
the input value is the number of degrees, same as RIGHT with a 
negative input) 

PENDOWN (O-input operation) put the turtle *s pen down so that when the 
PD turtle moves, It leaves a trace 

PENP * (O-input operation) return "TRUE" if the turtle's pen is 
Is down, "FALSE" if It is up 

PENUP (0-input operation) put the turtle's "pen" up so that when the 
turtle move*-, it leaves no trace 

PLOT '1-input operation) direct turtle commands to the robot turtle 
(input ~ -1, see UNPIGT) 

RIGHT (1-input operation) rotate the turtle right (clockwise, the 
Input Volue is the number of degrees, see LEFT) 

TOOT (0-input operation) toot the turtle's hom 

TOUCHBACK (0-input operation) return "TRUE" if the turtle's rear 
TB sensor is touching something, otherwise return '*FALSE" 

TOUCHFRONT (0-input operation) as for TOUCHBACK, but for front sensor 
TF 

TOUCHlEFr (0-input operation) as for TOUCHBACK, but for left sensor 
TL 
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TOUCHRIGHT (O-lnput operation) as for TOUCHBACK, but for right sensor 
TR 



UNPLOT (0-input operation) release the robot turtle for others to use 



IMSSS Logo Music Box Primitives 



The General Turtle music box is capable of producing sequences of 
synthesized tones from four simultaneous voices, as described below. 



NOTE (2-input operation) the first input is a sentence of pitches; 

notes are buffered by the music system until the PM (play music) 
command is typed; pitches are specified by a decimal number 
between -28 and 32 or by a notation of the form (<octave>)<note> 
(<flat>|<sharp>) , where: 

<octave> Is one of: (-2,-1.0 or <blank>,1,2) 
<note> is one of: (C,D,E,F,G,A,B) 
<flat> is < or - 
<sharp> is //, > or + 



Notation 


Number 


Tone 


%, REST 


-28 


silence 


BOOM 


-27 


"boom" percussion sound 


SH 


-26 


"sh" percussion sound 




-25 


(not used) 


-2C 


-24 


C, two octaves below middle C 


-2C// 


-23 


C sharp or D flat, same octave 


-2D 


-22 




-2D// 


-21 




-2E 


-20 




-2F 


-19 




-2F// 

• 


-18 

• 




• 

C 

• 


• 

0 

• 


middle C 


2G// 


32 


G-sharp, two octaves above middle 



note's second input is a sentence of pitch durations, which tell 
how long (e g. how many 1/30th seconds) to sustain or send the 
corresponding note — real-time duration thus depends on line 
speed and number of voices, so a duration of 30 for 1 voice 
lasts about 1 second — equal to a duration of 7 for each of 4 
voices (durations are between 1 and 127); for clear transitions 
between notes, a rest takes the place of the pitch at the end of 
the duration for durations >1; thus a duration of 1 sends the 
pitch once, 2 sends the pitch once and one rest, and so on 
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NVOICES (1 -input operation) the input is the number (betvsen 1 and 4) of 
"voices" (independent, simultaneous note sequences) desired (3 
voices is not recommended, see PM) ; it also erases any music 
already stored 

PM (0-input operation) play (and chen erase) music that has been 

stored; voices which run out of notes (while others are still 
playing) are sent rescs; (NVOICES 3 uses 4 voices, the fourth 
being entirely silent) 

VLEN (0-input operation) returns a sentence whose length is the 
number of voices; each word is the total duration for that 
voice 

VOICE (1 -input operation) sends all subsequent notes to some voice 
(the input: number is between 1 and 4, default is voice 1) 



2.2 Train 



One of the de>^ices controlled by IMSSS Logo is an electric train. 
Here we present the relevant Logo operations followed by a description 
of the train system. Any abbreviations a. 'e included beneath the full 
operation names, the number of inputs (arguments) required is noted in 
parentheses with the description of each operation, and denotes 
operations ncc normslly introduced to students 



IMSSS Logo Train Primitives 



BACK (1 -input operation) move the train backward a specific number of 
blocks (the input) 

CONNECT (1 -input operation) connect a sentence of three locations, i.e. 
cc:nnect first and third locations by setting the switch at the 
second location 

FRONT (1-input operation) move the train forward a specific number of 
blocks (the Input) 

HOME (0-lnput operation) move tiain to its starting loctation (see 
SETTRAIN) 
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SETSWITCH (2-lnput operation) set switch (the first Input) to some 
SW direction (the second Input: "S" Is straight, "C" Is curved, 

"CL" Is curved left, "CR" Is curved right; * "DIS!" means 
disable switch In current position, "ENA!" means enable 
switch (first Input can be "ALL")) 

SETTRAIN (1 -Input operation) set all switches straight; find the train 
(If at the terminal next to the layout), or begin a simulation 
by placing It at a starting location (the Input word) 

SPEED (2-lnput operation) set the speed (second Input (0,7), 0 means 
no change) for a direction ("F" or "B") and return the speed 

TRAINFO (1 -Input operation) return a sentence of Information about a 

location (the input word), for example "" (l.e« not a location), 
•track", "crossover", "switch 2WAY STRAIGHT WORKING" and so on 

TRMOVE * (2-lnput operation) move the train to a block (first Input) 
by the shortest route (approximately) ; if the second input is 
nonempty, TRMOVE just returns a sentence of route locations 

TROP * (3-lnput operation) general Sallogo operator; first input 
is the Sallogo command number, second and third Inputs are 
parameters; returns : EMPTY: or result of operation; this is 
a way new train, turtle or graphics commands may be tested 

WHERE (0-lnput operation) return a sentence of locations; first 
(last) word is the next location if the train goes forward 
(backward) intermediate words describe where the train is; 
track location names are of the form ("*" indicates that the 
track is not clear): <track number> <zone letter> ("X" for 
crossovers); for example: 1F,2E,2EX are clear, * IF is a 
working disconnected switch, **1F is a nonworklng disconnected 
switch, and *** is an end of track 

WHERETO (2-lnput operation) return a sentence of blocks accessible from 
given block (second input) in a direction away from the block 
named by the first input 

WHISTLE (0-lnput operation) train whistles (terminal bell rings) 



The IMSSS train system differs from the basic Marklln system in 
the following way: although the center rail is used for power, only one 
running rail is used for a ground return; the other rail is cut on 
block boundaries and is shorted to ground only when rolling stock with 
uninsulated axles enters a block. The Interface signals that something 
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entered or left block *'xy", thus leaving to the program (Sailogo) the 
task of inferring what is that something. Supplying power to the 
engine via the center rail precludes independent control of a second 
engine unless a catenary or carrier-control system were added. A 
catenary would, of course, make the layout even more difticult to 
change. The interface's design allows for two trains (one via 
catenary), but this has not been exploited. Obtaining marginally 
reliable performance of one train is troublesome enough. For instance, 
speed control is rough and unpredictable. Sailogo can command eight 
different speeds, but only the highest causes movement, and even that 
slackens on curves. The interface also allows for coupling and 
uncoupling, but the physical problems involved have not been surmounted. 
Experiments in manually adding cars to the train indicate that excessive 
noise is induced in block sensing. Design of a reliable layout and 
control system requires imagination, experience in both electronics a;7d 
model railroading, and plenty of time. We feel that an initial 
simulation of train and layout would have led to better results. 

Within Sailogo, knowledge about the track layout is incorporated in 
a linked list of track blocks (sections). Switches are blocks with 
added information about accessible, adjacent blocks. In setting a 
switch, the program checks that the switch is not occupied, replaces 
block links in the data structure, remembers the position of the switch 
(there is no hardware feedback on switch settings so all are initialized 

* We thank David Serres ot Seattle for consulting with us on potentially 
reliable train designs, 
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to be straight), and sends the appropriate ASCII character to throw the 
switch* 

When moving the train, the next block (forward or backward) cannot 
be a track end, be a disconnected switch, or be occupied. ASCII 
characters combining the train's direction and speed are sent to the 
train interface. To determine if the train is properly moving when 
feedback information is faulty (which can happen when track connections 
are dirty or loose), the program monitors a '^window" of blocks, 
hopefully containing the train, its previous block and the next two 
blocks in its direction of motion. A transition matrix defines which 
of sixteen combinations of feedback information are stable, noisy, or 
erroneous (e.g. "0100" is a stable configuration where the previous 
block is unoccupied (0), the current block is occupied (1), and the 
next two blocks are unoccupied). For example, if the train enters a 
block not In the window, a faulty switch may be the cause (the program 
could, but does not, incorporate this knowledge into Its world view); 
if the train skips a block (evg. 0001), a track sensor may have failed 
and this fact Is reported; when the train does not change state within 
a few seconds, a blcwn circuit-breaker or broken connection may be the 
culprit; and so on^ In this way, Sailogo attempts to ignore noise and 
classify and compensate for errors where possible. 

If we could have added multiple trains (either physically or in 
a simulation), theie remain problems with the Tenex control structure In 
allowing separate users to share a device and/or a changing, program 
data-base. As one solution, we added multiple Logo users as subsidiary 
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Tenex forks to one train job, which then acted as an executive to allow 
train commands to be executed in a shared environments This approach 
was frustrated because Logo lost the ability to handle pseudo -Interrupts 
unless they were generated by the additional terminals (in the current 
version of Tenex (1.31) at IMSSS, there may be but one controlling 
terminal per job). 

Appendix 3; Details Pertinent to the Preliminary Test 

This appendix contains a discussion of how one commercial designer 
of an aptitude test for computer programming ability attempted to assess 
the validity of that test. The test was examined in the process of 
designing our own test — a sampling of which appears in Appendix 3.2. 

3,1 An Example of Commercial Evaluatio n 

The example derives from remarks in the published manual for one of 
the tests we investigated. The validity of that test was assessed by 
three studies: (1) correlation of test scores and grades of three 
groups of programming trainees, (2) correlation of test scores and 
overall performance ratings by supei-visors of programmers, and (3) a 
study like that of (2) in which grades on a training course were also 
available. Studies (1) and (3) both assumed, without discussion, that 
the testing done during training was itself a valid measure of 
programming ability. Studies (2) and (3) both assumed that ratings by 
superiors was similarly valid. Study (1) indicated that, of fifteen 
relevant correlations between subtest scores and trainee groups, eight 
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were of statistical significance* And only one subtest was 
significantly zorrelated with trainee performance over all groups, in 
spite of the fact that the overall test/training correlation for each 
group was significant* Interestingly, the most variable subtests were 
those which relied heavily on time and repetition. In Study (2), three 
of five subtest correlations and the overall correlation were 
significant but small; and the two remaining subtests were those which 
exhibited variable or minimal correlation with performance in study (1). 
Unfortunately, the ratings used as the validating measure in (2) were 
not confined to programming ability and included such things as 
attitudes. Therefore, study (2) is invalid. Study (3) found three 
subtests significantly correlated with training course grades, but one 
of the three had not been significantly correlated with grades for any 
group in study (1). Furthermore, the ratings used in the other half of 
study (3) were virtually uncorrelated with subtest results , The 
brochure went on to state that these ratings and job tenure were 
correlated more strcngly than anything else in both halves of the study 
— the saggescion being that low correlations must be expected when 
evaluaticns pla .e high value on relatively invalid properties (i,e. 
tenure)* An alternatice observation can be made which applies to any 
correlational piwcedure: the sample variance of a measured property may 
be so lew that apparent but spurious correlations with another measure 
arise. In study O), the test scores could have had low variability 
for good reason: the testees could have been of very nearly the same 
competence. In any e<rent, ncne of the studies presided a clear 
validation c£ this parCi^ular tsst tor pr:.gxamming aptitude. 
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Appendix 4: Sample Logo Curriculum 

This appendix contains portions of the Logo curriculum developed 
for the experiment discussed jr this report. Many of the excerpts 
shown here are referenced by discussions in the text, particularly in 
Sections 4.1 and 6^1. The following table indexes the curriculum by 
part number, curriculum page, and page of this appendix. Pages denoted 
with "T" were designed for use by turtle-graphics students. The text 
is copyrighted, but may be used for noncommercial purposes. 



Part 


Curriculum Page 


Page 


1 


1,4 


173 


2 


8 


■ 174 


3 


15,17T,17.2T 


174-175 


4 


18,21,22 


176-177 


5 


26-30 


177-179 


6 


3if, 40-42, 44T 


180-182 


7 


46,47,50,54,54T 


182-184 


8 


55,59,61,63 


185-186 


9 


65,66,68,70,72,74,75 


187-190 


10 


76-78, 79T, SOT, 81, 82, 84, 85 


190-194 
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Appendix 5: Sample Simper Currlcultam 

This appendix contains portions of the Simper currlculimi developed 
for the experiment discussed in this report* Many of the excerpts 
shown here are referenced by discussions in the text, particularly in 
Sections 4.2 and 6.1. The following table Indexes the curriculum by 
part number, curriculum page, and page of this appendix. The text is 
copyrighted, but may be used for noncommercial purposes. 



Part 


Curriculum Page 


Page 


1 


see Logo index 


172 


2 


6,12 


196 


3 


13,15,17,19 


197-198 


4 


22,24 


199 


5 


27,30,35,37 


200-201 


6 


40,45 


202 


7 


46-48,52,53 


203-205 


8 


57,60 


205-216 


9 


61,62 


206-207 


10 


67-69,72,73 


207-209 


11 


77-80 


210-211 


12 


82,85-87,89 


212-214 


13 


91,94,97 


214-215 



195 




ER|C 196 ^0(4. 
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